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I.  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  thesis  is  to  provide  mid-level  and  top-level  managers  at  the  Office 
of  Naval  Intelligence  (ONI)  with  a  risk  assessment  and  “state  of  the  art”  report  on  factors 
associated  with,  and  affecting,  the  key  decision  to  “downsize”  information  systems.  Most 
often  typified  by  the  architectural  transition  from  large,  centralized  mainframe  systems  to 
a  network  of  distributed  workstations,  the  downsizing  issue  is  currently  one  of  the  most  dif¬ 
ficult  and  critical  strategic  decisions  facing  bodt  corporate  and  government  organizations. 
The  decision  to  downsize  is  particularly  important  in  light  of  the  new  budget  constraints, 
the  reduction  of  personnel  associated  with  the  tighter  budget,  and  resulting  pressure  to  ac¬ 
complish  “more  with  less.”  Few  would  dispute  die  harkening  of  a  new  world  era —  the  post¬ 
industrial  age  of  irtformation  — where  efficient  collection,  processing,  and  dissemination  of 
irrformation  is  becoming  a  strategic  necessity.  This  thesis  is  written  as  a  consequence  of 
new  technologies  that  have  enabled  better,  faster,  and  cheaper  options  of  processing  that 
information.  These  new  innovations  in  technology  have  generated  new  methods  of  process¬ 
ing  information,  new  architectures.  Those  organizations  that  understand  when,  where,  and 
how  to  select  the  most  advantageous  of  these  architectures  will  better  be  able  to  meet  their 
budget,  achieve  maximum  productivity  from  their  personnel,  and  accomplish  defined 
goals.  This  thesis  will  try  to  provide  some  background,  insight,  and  suggestions  to  the 
“where,  when,  and  how”  of  downsizing. 

Though  this  thesis  is  written  in  response  to  research  requirements  prompted  by  mid¬ 
level  and  top-level  managers  at  ONI,  significant  portions  this  thesis  are  applicable  to  any 
large-scale  organization,  government  or  corporate,  with  sizable  investments  in  information 
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systems.  The  research  conducted  in  the  completion  of  this  thesis  primarily  dealt  with  liter¬ 
ature  reviews  and  case  studies  associated  with  private  business  organizations.  Undeniably, 
however,  there  are  lessons  to  be  learned  by  DoD  through  the  study  of  the  corporate  world. 
After  examination  of  the  most  widely  relevant  downsizing  issues,  the  final  segment  of  this 
thesis  will  briefly  “frame”  the  most  pertinent  issues  for  DoD  organizations  in  general,  and 
ONI  in  particular. 

B.  BACKGROUND 

This  thesis  is  being  written  for  the  Office  of  Naval  Intelligence  (ONI)  located  in  Suit- 
land,  Maryland.  ONI  is  responsible  for  the  collection,  production,  and  dissemination  of  Na¬ 
val-related  intelligence  information  to  satisfy  the  requirements  of  the  Department  of  the 
Navy  (DoN),  operating  forces  and  commands,  the  research  and  development  (R&D)  com¬ 
munity,  the  Department  of  Defense  (DoD),  the  Defense  Intelligence  Agency  (DIA),  and 
national  command  authorities  and  agencies. 

In  support  of  its  mission,  ONI  manages  a  large  array  of  naval  intelligence  automated 
data  processing  systems  that  includes  older  technology  mainframe  computer  systems. 
These  computer  systems  serve  as  hosts  for  extremely  large  databases  supporting  mission 
areas  such  as  scientific  and  technical  data,  worldwide  merchant  shipping,  countemarcotics, 
digital  imagery,  inter  alia. 

The  current  and  future  fiscal  environment  mandates  that  ONI  initiate  cost  savings  pro¬ 
grams  within  the  automated  systems  department,  while  ensuring  these  efforts  do  not  ad¬ 
versely  impact  the  operational  support  mission  of  the  command.  These  reductions  include 
cuts  in  system  support  hardware,  software  life-cycle  support  and  training  costs.  This  situ¬ 
ation  is  being  exacerbated  with  increasing  requirements  such  as  new  on-line  databases  as 
part  of  the  worldwide  Department  of  Defense  Intelligence  Information  System  (DODllS) 
Wide  Area  Network  (WAN).  Finally,  in  mid- 1994,  ONI  will  be  moving  into  a  new 
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building — currently  under  construction — and  wants  to  examine  the  issues  of  replacing 
large  mainframes  with  smaller  workstation  systems  in  the  new  environment  without  losing 
functionality. 

ONI  submitted  a  proposal  for  a  thesis  research  topic  to  the  Naval  Postgraduate  School 
(NPS)  that  suggested  a  risk  analysis  “on  downsizing  from  large  mainframe  computer  sys¬ 
tems  to  high-end,  client-server  workstation  as  it  applies  to  system  performance,  personnel 
reductions,  and  system  cost  savings."  One  of  ONl*s  proposed  approaches  was  for  NPS  to 
perform  a  systems-level  risk  analysis  based  upon  a  case  study  of  a  major  commercial  firm, 
such  as  Mobil  Oil  or  the  IBM  Credit  Union,  which  downsized  from  larger  mainframe  com¬ 
puter  systems  to  high-end,  client/server  workstations.  ONI  made  it  clear  that  a  case  study 
was  only  a  suggested  approach  and  left  it  to  researcher  discretion  to  determine  the  most  ap¬ 
propriate  manner  to  address  the  pertinent  downsizing  issues.  As  already  hinted  in  the  pre¬ 
vious  section  and  outlined  in  the  next  section,  it  was  ultimately  determined  that  an 
academic  overview  and  survey  of  the  most  relevant  downsizing  issues  would  better  suit 
ONI  and  DoD  needs  than  a  focus  on  one  particular  case  study. 

ONI’s  proposed  research  suggested  focusing  on  lessons  learned  in  the  downsizing 
process  including  technical  systems  performance  problems,  cost  savings,  and  management 
issues.  ONI  was  also  interested  in  how  new  technologies  could  be  inserted  into  their  infor¬ 
mation  systems  to  help  reduce  the  risk  factors  in  downsizing  the  automated  data  processing 
systems,  while  simultaneously  optimizing  system  functionality,  manpower  reduction  trade¬ 
offs,  and  system  hardware  and  software  maintenance  costs. 

A  visit  was  made  to  ONI  to  ascertain  the  scope  of  the  downsizing  envisioned  and  to 
enable  tailoring  of  the  research  for  use  by  the  command.  During  the  visit,  the  thesis  spon¬ 
sors  emphasized  that  they  would  like  the  research  to  focus  not  on  the  command  itself,  but 
other  corporate  models.  They  did  not  want  an  “answer”  on  how  ONI  should,  in  detail, 
downsize.  They  believed  that  with  an  understanding  and  appreciation  of  ONI’s  size  and 


complexity,  appropriate  case  studies  and  an  academic  approach  would  best  serve  their 
purposes. 

ONI’s  intention  is  to  stay  abreast  of  fast  moving  technology  and  to  meet  growing  cus¬ 
tomer  demands  and  requirements.  The  command  is  investigating  new  options,  new  tech¬ 
nology,  and  new  opportunities.  The  most  appealing  option  that  ONI  is  investigating  is 
downsizing  to  a  client/server  environment  with  high-end  performance  workstations.  If  the 
command  can  increu.se  mission  effectiveness  and  save  money  through  such  an  option  then 
it  will  further  pursue  that  objective. 

C.  THESIS  SCOPE  AND  OUTLINE 

The  thrust  of  this  thesis  will  be  a  survey  of  the  trends,  concepts,  methodologies,  and 
management  strategies  associated  with  the  downsizing  process.  Because  the  issues  related 
to  downsizing  involve  both  management  and  technological  issues,  each  dependent  on  the 
other,  this  paper  will  address  both  management  and  technical  perspectives. 

The  downsizing  momentum  has  been  fed  by  these  two  equally  significant  forces.  On 
one  hand,  technology  has  been  driving  managers  to  re-think  they  way  their  organizations 
handle  information.  It  has  required  top  managers  to  streamline  and  re-engineer  their  busi¬ 
ness  processes  in  order  to  capitalize  on  new  technological  opportunities.  On  the  other  hand, 
pressures  to  do  “more  with  less”  and  subsequent  implementations  of  new  management 
schemes  (e.g..  Total  Quality  Leadership  (TQL)  and  Business  Process  Reengineering 
(BPR))  have  forced  managers  to  consider  how  technology  might  assist  them  in  coping  with 
new  management  initiatives.  The  downsizing  of  Ute  corporate  structure  is  directly  linked  to 
the  down.sizing  of  information  systems.  As  corporations  aim  to  streamline  their  organiza¬ 
tion  and  personnel,  they  look  to  technology  for  solutions.  Thus,  neither  the  management  or 
technical  aspects  of  downsizing  information  systems  should  be  considered  without  giving 
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attention  to  the  other;  the  two  are  inextricably  linked.  This  thesis  will  reflect  that 
relationship. 

Before  outlining  the  specitic  topics  of  discussion  in  this  thesis,  it  is  important  to  put 
a  bound  on  this  obviously  broad  topic  in  which  many  sub-topics,  by  themselves,  could  eas¬ 
ily  be  addressed  in  separate  theses.  This  thesis  has  an  ambitious  objective  in  that  any  of  the 
subsequent  chapters  have  been  tackled  by  many  different  authors  in  many  volumes  of 
books  and  other  publications.  Here,  1  point  out  that  this  thesis  will  be  a  broad-brush  survey 
of  the  downsizing  issues,  not  unlike  an  executive  “white  paper”  typical  of  larger  organiza¬ 
tions.  This  thesis  will  identify  the  major  issues  related  to  downsizing  without  delving  into 
too  much  detail.  It  will  provide  a  comprehensive  analysis  of  both  management  and  techni¬ 
cal  is.sues,  putting  them  in  context  with  trends  in  computing.  Most  importantly,  this  thesis 
will  “frame”  the  downsizing  trend,  not  offering  any  one  solution,  but  offering  ways  of 
thinking  about  downsizing  and  methods  of  approaching  it  in  the  context  of  one’s  own 
organization. 

Downsizing  information  systems  can  regarded  as  an  inevitable  result  of  evolving, 
more  capable  technology.  Simply  put,  the  evolution  of  computing  technology  from  the 
mainframe  in  the  “glass  house”  to  the  personal  computer  on  the  desktop  has  created  a  rev¬ 
olution.  This  “revolution  in  computing”  has  generated  new  ways  of  thinking  about  infor¬ 
mation  technology  as  an  integral  part  of  an  organization’s  strategy.  The  advent  of  desktop 
computing  has  enabled  managers  to  think  of  new  ways  that  IT  can  help  an  organization  ob¬ 
tain  its  objectives.  Top  managers  have  been  used  to  thinking  about  computing  within  a  spe¬ 
citic  “mold”  or  context.  Now,  new  technology  has  created  an  environment  for  a  new  way 
of  thinking  about  computing. 

The  second  chapter  in  this  thesis  (the  first  chapter  being  this  introduction)  encapsu¬ 
lates  this  new  way  of  thinking,  or  “paradigm  shift.”  This  chapter  first  sets  the  stage  by  de¬ 
scribing  the  changing  business  environment  and  the  accompanying  mandate  for  change.  It 
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describes  how  IT  has  become  closely  linked  with  strategy,  and  how  IS  architectures  are  tied 
to  those  strategies.  Finally,  it  summarizes  the  shift  from  traditional  mainframe  computing 
to  desktop  computing  and  the  resulting  trend  of  downsizing. 

The  third  chapter  will  provide  an  overview  of  architectural  decisions  related  to  the 
downsizing  process.  This  will  include  a  focus  on  establishing  the  appropriate  architecture 
with  emphasis  on  the  client/server  model,  and  the  evolving  role  of  the  mainft'ame,  mini¬ 
computer,  and  microcomputer  within  that  architecture.  The  last  part  of  this  chapter  will  out¬ 
line  the  various  architectural  tools  and  architectival  trends  that  have  helped  fuel  the 
downsizing  movement  and  have  helped  change  the  way  organizations  view  computing. 

The  fourth  chapter  in  this  thesis  discusses  risk  analysis  issues  and  factors  that  must  be 
considered  in  the  decision  making  process  of  whether  or  not  to  downsize.  The  chapter  in¬ 
volves  a  discussion  of  both  qualitative  and  quantitative  issues.  First,  it  is  imperative  to  look 
at  the  organization  as  a  whole  and  to  define  IT’s  role  within  it  IT-related  processes  need  to 
be  examined  and  evaluated  in  conjunction  with  the  organizational  goals.  Here,  a  brief  over¬ 
view  of  some  of  the  new  management  initiatives  will  be  conducted.  Next  this  chapter  shifts 
from  an  organizational  aspect  of  risk  analysis  to  an  examination  of  performance  factors. 
Again,  in  discussing  performance-related  considerations,  the  discussion  will  survey  a  wide 
gamut  of  issues  from  speed  to  security  to  maintenance  of  systems.  Finally,  in  the  last  part 
of  the  chapter,  I  will  discuss  methods  of  cost-justifying  downsizing.  This  will  entail  both 
quantitative  and  qualitative  evaluations. 

The  final  chapter  will  “frame”  and  summarize  the  key  downsizing  issues  relative  to 
DoD  and  ONI  requirements.  This  will  include  a  discussion  of  how  the  corporate  environ¬ 
ment  downsizing  considerations  may  differ  from  those  of  the  military.  Corporate  “lessons 
learned”  will  be  extracted  and  highlighted  to  give  top  managers  some  general  guidelines 
from  which  they  can  intelligently  plan  .strategy  and  make  key  decisions.  Undoubtedly,  the 
downsizing  process  has  the  potential  to  be  an  unstructured  and  haphazard  exercise  in 
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frustration  that  can  lead  to  huge  cost  over-runs  and  even  IS  failures.  Hopefully,  this  final 
chapter  will  highlight  the  most  applicable  issues  and  provide  a  structured  guideline  to  a 
complex  and  seemingly  overwhelming  process. 
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n.  THE  PARADIGM  SHIFT 


A.  THE  CHANGING  ENVIRONMENT 

Chanffe  is  the  only  constant.  This  phrase  is  as  applicable  to  the  information  systems 
world  as  it  is  to  the  current  political  and  economic  climate.  Increased  global  competition, 
the  need  for  global  management,  reduced  product  cycles,  changing  demographics,  and  the 
growing  power  of  knowledge  are  all  key  forces  driving  escalating  demands  on  information 
systems.  The  world  is  changing  at  a  pace  perhaps  more  rapid  than  ever  before.  What  impli¬ 
cations  does  this  hold  for  informations  systems  level  in  both  the  Department  of  Defense  and 
the  corporate  world?  In  this  information  age  where  knowledge  means  power,  it  translates 
into  a  need  for  information  systems  that  are  capable  of  handling  huge  volumes  of  data 
quickly,  globally,  securely,  flexibly,  and  efficiently.  In  this  post-industrial  era,  hie  new  com¬ 
modity  is  information.  Those  corporations,  organizations,  or  even  nations  for  that  matter, 
that  are  capable  of  collecting,  analyzing,  and  responding  to  new  information  will,  in  short, 
dominate  the  world  stage. 

B.  INFORMATION  TECHNOLOGY  AS  STRATEGIC  ASSET 

Presunung  acceptance  of  the  value  and  power  of  information,  one  readily  sees  the  ne¬ 
cessity  of  incorporating  IT  into  a  corporate  or  organizational  strategy.  IT  is  the  engine  of 
change  that  will  propel  some  organizations  into  the  future,  while  leaving  others  with  less 
foresight  to  wither  away  in  obsolescence.  IT  is  the  enabling  force  that  permits  the  handling 
of  collection,  analysis,  and  intelligent  responses  to  large  volumes  of  information.  Incre¬ 
mental  differences  in  the  capabilities  and  flexibility  of  those  “engines"  will  clearly  separate 
the  winners  from  the  losers.  Thus,  recognition  of  IT  as  a  strategic  asset  and  incorporating 
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it  as  a  core  element  into  an  organization’s  strategy  is  a  first  step  in  securing  a  foothold  in 
this  globally  competitive  market. 

IT's  strategic  role  can  be  categorized  within  three  specific  areas: 

•  as  competitive  tools 

•  to  reengineer  business  processes 

•  for  interorganizational  linkage  [Ref.  I  :p.  69] 

1.  IT  as  a  Competitive  Tool  and  Strategic  Necessity 

Other  factors  being  equal,  information  strategists  readily  recognize  effective  cor¬ 
porate  implementation  of  IT  as  a  competitive  tool  that  is  quickly  becoming  a  strategic  ne¬ 
cessity.  Organizations  are  realizing  that  if  they  fail  to  properly  capitalize  on  this  resource, 
they  will  simply  not  stay  in  business.  William  Davidow  and  Michael  S.  Malone,  authors  of 
The  Virtual  Corporation,  acknowledge  information  processing  as  the  “most  important 
power  source  of  our  generation”  in  structuring  and  revitalizing  the  corporation  for  the  2 1st 
century  [Ref.  2:p.  2).  At  the  corporate  level,  the  authors  state  that  “in  the  years  to  come, 
incremental  differences  in  companies’  abilities  to  acquire,  distribute,  store,  analyze,  and  in¬ 
voke  actions  based  on  information  will  determine  the  winners  and  losers  in  the  battle  for 
customers”  [Ref.  2:p.  50]. 

In  general,  market  dynamics  do  not  permit  organizations  to  maintain  a  competi¬ 
tive  advantage  with  IT.  Under  unique  circumstances,  a  competitive  advantage  can  be  sus¬ 
tained  long  enough  that  it  can  become  a  strategic  advantage.  Davidow  and  Malone  provide 
such  an  example.  Extending  the  argument  beyond  the  corporate  level  to  the  military  and 
illustrate,  they  illustrate  the  undeniable  power  of  information  in  the  Persian  Gulf  War: 

Why  the  rout?  The  answer  was  obvious  to  anyone  watching  television  during  the 
brief  course  of  the  war.  The  Allied  troops  had  information  on  the  Iraqis  far  superior 
to  any  information  held  by  their  enemy  and  then  managed  that  information  more  ef¬ 
fectively.  In  strategic  command  and  control,  the  Allies  used  satellite  and  reconnais¬ 
sance  information  to  learn  just  about  everything  they  needed  to  know  about  Iraq’s 
static  defenses.  Tomahawk  cruise  missiles,  using  reconnaissance  information  stored 
in  their  memories,  were  so  well  programmed  that  they  actually  followed  roads  and 
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streets  to  their  targets.  Further,  because  the  Allies  appreciated  the  importartce  of 
information,  they  also  knew  the  value  of  denying  it  to  the  other  side....  With  the  Per¬ 
sian  Gulf  War,  ^e  value  of  information  reached  a  zenith — bytes  became  nnore  im¬ 
portant  than  bullets.  The  case  was  made,  with  brutal  clarity,  that  information  could 
become  the  foundation  for  devastating  destruction.  [Ref.  2:p.  SI] 


Though  this  example  may  take  the  notion  of  strategic  advantage  to  an  extreme,  it 
effectively  illustrates  the  information  systems  role  as  a  force  multiplier  for  both  business 
and  defense  applications  and  as  a  critical  component  in  formulation  of  strategy. 


2.  Using  IT  to  Reengineer  Business  Processes 

Incorporation  of  IT  into  an  organization’s  mission  will  not  guarantee  organiza¬ 
tional  success;  technology,  by  itself,  is  not  a  panacea.  A  new  IS  may  speed  up  an  organiza¬ 
tions’s  proces.ses,  but  if  the  organization’s  processes  are  already  broken,  automation  of 
those  processes  will  only  result  in  nominal  improvements.  IS  managers  should  not  rush  out 
and  assume  that  throwing  technology  at  a  problem  will  secure  a  competitive  advantage. 

Although  the  emphasis  in  the  1980s  was  on  using  IT  for  comi«titive  advantage,  the 
thrust  in  the  early  1990s  has  turned  inward,  specifically  to  using  IT  as  a  catalyst  to 
‘reengineer’  outmoded  business  practices...  mean(ing)  fundamentally  redesigning 
how  the  enterprise  works — its  procedures,  control  mechanisms,  reporting  relation¬ 
ships,  decision  makers,  compensation  criteria,  and  so  forth — and  generally  making 
IT  an  integral  part  of  operations.  The  goal  is  to  rid  the  firm  of  ways  of  working  that 
were  appropriate  for  the  paper-based  world,  and  replace  them  with  work  modes  that 
leverage  the  attributes  of  FT.  [Ref.  1  :p.  82] 

Prior  to  utilization  of  any  new  architecture,  the  business  processes  must  be  exam¬ 
ined.  Business  process  re-engineering,  according  to  IT  consultant  Michael  Hammer — one 
of  the  gurus  of  business  process  reengineering — is  about: 


...  scrapping  every  belief,  every  method,  every  process — and  then  rebuilding  the  or¬ 
ganization  in  entirely  new  ways...  Simply  put,  information  technology  is  al^Iutely 
essential  to  re-engineering.  It  is  the  single  most  powerful  tool  for  bre^ng  traditional 


assumptions  and  rules,  and  the  thing  that  makes  new  ways  of  operating  possible. 
[Ref.3:p.  11-12] 


Recognition  that  competitive  advantage  can  be  gained  through  the  use  of  technol¬ 
ogy  is  a  preliminary  step — but  realization  that  a  significant  improvement  in  performance 
can  be  achieved  only  through  an  organization’s  reengineering  of  its  business  processes  is 
essential.  An  organization  needs  to  break  down  its  functions,  determine  the  value-added 
processes,  and  streamline  the  organization  accordingly. 


3.  Using  IT  for  Interorganizational  Linkage 

IT’s  third  strategic  role  is  inherent  in  its  ability  to  provide  automated  communi¬ 
cation  mechanisms  with  other  departments  or  organizations.  With  the  globalization  of  the 
world  economy,  the  need  for  interoganizational  linkage  is  quickly  growing.  From  the  forg¬ 
ing  of  strategic  alliances  to  the  maintenance  of  corporate  accounting,  the  interchange  of 
electronic  data  can  allow  organizations  to  maintain  critical  partnerships  without  the  con¬ 
straints  of  space  and  time.  This  flexibility  is  particularly  significant  for  today’s  corporation 
that  needs  to  be  increasingly  cognizant  of  and  responsive  to  changing  market  trends  and 
customer  demands.  The  “virtual  product”  described  in  Davidow’s  and  Malone’s  virtual 
corporation  of  the  21st  century  is  the  embodinwnt  of  the  ideal: 

A  virtual  product  (the  term  is  used  to  mean  both  physical  products  and  services) 
mostly  exists  even  before  it  is  produced.  Its  concept,  design,  and  manufacture  are 
stored  in  the  minds  of  cooperating  teams,  in  computers,  and  in  flexible  production 
lines...  What  these  products  and  services  have  in  common  is  that  they  deliver  instant 
customer  gratification  in  a  cost-effective  way.  They  frequently  can  be  produced  in 
diverse  locations  and  offered  in  a  great  numt^  of  rmxlels  or  format..  The  idetd  vir¬ 
tual  product  or  service  is  one  that  is  produced  instantaneously  and  customized  in  re¬ 
sponse  to  consumer  demand.  [Ref.  2:p.  4] 

Electronic  Data  Interchange  (EDI),  the  business-to-business  computer  exchange 
of  common  business  transactions,  is  one  example  of  interorganizational  linkage  that  has  be¬ 
come  pervasive  throughout  many  different  industries.  The  topic  of  interorganizational 
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linkages  is  a  thesis  topic  in  itself;  nevertheless,  this  aq)ect  of  IT  undeniaUy  warrants  con¬ 
sideration  as  a  critical  component  of  an  organizations's  overall  strategy. 

C.  THE  CHANGING  INFRASTRUCTURE 

The  previous  section  outlined  three  significant  roles  that  IT  can  have  in  an  organiza¬ 
tion’s  overall  strategy.  Now  the  goal  of  top  managers  must  be  to  try  define  the  IS  architec¬ 
ture  and  its  infrastructure  that  will  enable  their  organizations  to  implement  those  strategies. 
The  IS  architecture  is  the  means  to  the  end.  To  a  large  degree,  the  molding  of  the  IS  archi¬ 
tecture  to  the  organizational  strategy — thereby  obtaining  the  “best  fit” — will  determine  the 
degree  of  the  strategy’s  success. 

For  large  organizations  dependent  on  mission-critical  applications,  the  traditionally 
appropriate  IS  architecture  has  been  the  centralized  architecture  built  around  the  capabili¬ 
ties  of  the  mainframe.  Until  recently,  for  some  corporations,  the  mainframe  has  been  the 
only  feasible  solution  to  meeting  performance  requirements.  The  increased  processing  ca¬ 
pability  of  the  de.sktop  computer  and  the  advent  of  networking  technology  has  increased 
the  range  of  architectural  options.  The  desktop  revolution  has  unwrapped,  to  a  degree,  a 
mentality  that  has  been  fixated  around  the  mainframe.  This  next  section  takes  a  took  at  these 
evolving  performance  trends — a  discussion  of  traditional  mainframe  computing,  the  ad¬ 
vance  of  desktop  computing,  and  the  resultant  downsizing  “paradigm  shift” 

1.  Mainframe  Computing 

Mainframe  computing  has  been  the  traditional  computing  architecture  during  the 
past  three  decades — the  term  mair^rame  being  coined  back  in  the  early  ‘60s  with  reference 
to  the  large  and  bulky  metal  cabinets  where  the  central  processing  units  (CPUs)  were 
stored.  The  mainframe  has  essentially  dominated  the  state  of  computing  architectures  since 
the  development  of  the  first  digital  computer  (ENIAC)  in  the  mid  1940s  and  the  successful 


commercialization  of  the  UNIVAC  in  the  1950s.  It  has  been  the  “mold”  that  shaped  the 
architectural  paradigm  for  three  decades.  Companies  have  structured  their  processes 
around  the  mainframe,  aware  of  both  its  overall  strategic  importance  of  confuting  power 
and  the  criticality  of  efficient  information  processing.  Typically,  the  mainframes  have  host¬ 
ed  mission-critical  applications,  without  which  the  organization  could  not  continue  to  op¬ 
erate.  Evolving  from  almost  strictly  scientific  applications  and  batch  processing  to  wide- 
ranging  business  functions  and  on-line  transaction  processing  (OLTP),  the  mainframe  has 
helped  organizations  collect  and  store  increasingly  voluminous  amounts  of  data,  process 
complex  transactions  quickly  and  effectively,  and  analyze  and  assimilate  the  resulting 
flood  of  data. 

Though  the  mainframe  has  been  characterized  as  the  backbone  of  the  computing 
industry  and  will  surely  continue  to  play  a  major  role  in  the  future  of  the  computing  indus¬ 
try,  every  major  strength  of  the  mainframe  seems  to  inevitably  result  in  a  countering  weak¬ 
ness.  The  impressive  sophistication  of  mission-critical  applications  that  meets  all  needs  for 
all  users,  for  example,  is  not  only  extremely  expensive  to  develop,  but  typically  fhistrating- 
ly  expensive  and  difficult  to  maintain.  Compared  to  the  new  opportunities  available  on 
emerging  alternatives,  the  significant  strength  s  of  the  mainframe  are  becoming  less 
attractive. 

a.  Major  Shifts  in  Computing  Requirements 

The  nature  and  role  of  today’s  mainframe  has  been  set  by  a  historical  prece¬ 
dent.  Until  the  197Us,  there  was  no  real  alternative  to  mainframe  computing;  large-scale 
computing  was  the  only  feasible  solution  to  computing  problems.  Additionally,  the  hard¬ 
ware  at  the  time  was  extremely  expensive  and  software  was  relatively  cheap.  Almost  all 
applications  were  developed  to  run  in  the  batch-mode.  On-line  transaction  processing  was 
.still  in  its  infancy.  The  relative  simplicity  of  core  applications  processed  in  the  batch-mode 
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translated  into  relatively  high  productivity  and  throughput  and  resulted  in  respectable  cost 
savings. 

Dan  Trimmer,  author  of  Downsizing:  Strategies  for  Success  in  the  Modern 
Computer  World,  suggests  that  the  today’s  busimss  requirements  have  changed  since  the 
I97()s.  He  further  states  that  the  design  precedents  tiiat  have  typified  mainframe  computers 
have  handicapped  their  ability  to  meet  the  new  demands.  He  categorizes  those  changing 
business  requirements  by  three  major  shifts: 

(1)  Transition  to  an  Interactive,  On-Line  Environment  Batch-mode  pro¬ 
cessing  does  not  meet  the  needs  and  requireno^.nts  of  today’s  end-user.  With  the  exception 
of  back-ups  and  maintenance  of  files,  on-line  transaction  processing  has  become  the  norm 
for  many  organizations. 

(2)  New  Variety  in  the  Applications  Spectrum.  Requirements  for  applica¬ 
tions  have  become  much  more  complex  than  before.  In  addition  to  the  core  applications, 
end-users  are  demanding  eiror-handUng  and  unanticipated  decision  support  capabilities  to 
.serve  management  demands. 

(3)  Sophistication  of  End-users.  End  users  have  become  much  more  com¬ 
puter  literate  in  the  last  two  decades  and  are  demanding  more  of  their  systems. 
[Ref.  4:p.  35] 

b.  Costly  and  Complicated  Hardware  and  Software 

Concerns  regarding  cost  are  probably  the  primary  motivating  factors  that 
stimulate  criticisms  about  the  mainframe  computer.  Not  unrelated  to  the  high  costs  are  mis¬ 
givings  about  the  associated  conqrlexity  of  related  software.  One  underlying  reason — 
linked  to  its  historical  precedent — is  that  the  mainframe  has  attempted  to  be  all  things  to  all 
people. 
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(1)  Hardware  Costs.  Because  of  the  complex  designs  and  low- volume 
manufacturing  (in  a  declining  market)  of  mainframe  computers,  the  high  hardware  costs  are 
one  of  its  most  distinguishing  features. 

TaUe  1:  3090  PROCESSOR  PURCHASE  PRICES  [Ref.  S] 


Model  Number 

Purchase  Price 

340 

$2,125,000 

500 

$4,100,000 

580 

$5,715,000 

620 

$8,050,000 

720 

$10,545,000 

820 

$16,025,000 

900 

$22,280,000 

As  shown  by  Table  1  ’s  purchase  prices  of  IBM  3090  processors,  the  main¬ 
frame  costs  pale  next  to  mini  and  microcomputers  in  a  cost  comparison— despite  advancing 
technology  and  falling  prices  of  central  processors  and  solid  state  memoi^.  Not  only  does 
the  complexity  of  the  hardware  elevate  these  high  prices  of  central  processors  to  this  $2 
million  to  $22  million  range  (in  early  1990  figures),  but  also  the  combined  neod  for  pre- 
.sales  support  and  extensive  marketing. 

(2)  Hardware  Complexity.  Due  to  industry  attempts  to  serve  all  needs  of  all 
customers  combined  with  the  establishment  of  early  standards,  the  hardware  on  the  main¬ 
frame  is  not  only  extremely  expensive,  but  also  very  complex.  Elaborate  inpul/output  sys¬ 
tems  and  complicated  processor  and  processor-to-memory  relationships  exacerbate  the 
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situation.  Author  Dan  Trimircr  refers  to  this  development  as  the  “over-engineered  main¬ 
frame”  and  uses  the  diagram  illustrated  in  Figure  1,  below,  to  highlight  the  point 


Figure  l;Tlie  **Over-engineered  Mainframe”  [Ref.  4:p.  39] 


(3)  Software  Costs.  Software  packages  developed  for  mainframes,  like  the 
mainframe  hardware  itself,  tend  to  be  very  expensive.  Unlike  software  for  personal  com¬ 
puters,  mainfr^une  software  is  developed  by  relatively  few  companies — resulting  in  less 
competition  and  higher  prices.  Furthermore,  mainframe  software  developers  simply  are  un¬ 
able  to  di.stribute  their  high  fixed  costs  of  software  development  to  the  same  large  market 
share  that  the  desktop  computer  enjoys.  Those  few  corporations  that  purchase  a  common 
mainframe  software  package  must  absorb  the  high  fixed  costs  among  themselves  (the  vari¬ 
able  costs  of  software  development  are  relatively  insignificant  compared  to  the  fixed  costs). 
Also,  because  mainframe  software  is  often  custom  developed  for  an  organization,  analysis 
of  user  requirements  becomes  critical  and  software  must  be  tailored  to  meet  specific  needs. 
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This  process  is  time  consuming  and  costly.  If  requirements  are  not  properly  defined,  how¬ 
ever,  the  costs  grow  even  larger. 

In  the  personal  computer  market,  the  fixed  costs  of  developing  less  sophisti¬ 
cated  packaged  software  are  simply  not  as  high  as  those  of  the  mainframe.  Along  with  low¬ 
er  fixed  costs  and  relatively  insignificant  variable  costs,  desktop  software  developers  have 
the  additional  advantage  of  potentially  exploiting  a  huge  market  base.  This  economic  situ¬ 
ation  combined  with  the  intense  competition  among  personal  computer  software  develop¬ 
ers  both  serve  to  keep  the  price  of  desktop  software  very  low. 

(4)  Software  Complexity.  The  alphabet  soup  of  software  related  to  the  core 
functionality  of  the  various  mainframes  has  proved  to  be  detrimental  to  its  continuing  suc¬ 
cess.  The  common  perception  is  that  of  incompatibility  and  proprietorship  among  the  var¬ 
ious  systems.  Table  2’s  outline  of  the  various  operating  systems,  transaction  monitors, 
databases,  and  program  generators  common  to  large  and  small  mainframes  illustrates  the 
problem. 


Table  2:  MAINFRAME  SOFTWARE  [Ref.  4;p.40] 


Type  of 
Machine 

Transaction  or 
Production 

Information-Center 

Large 

Mainframe 

CSP 

AS 

IMS-DB 

DB2 

CICS 

TSO 

MVS 

MVS 

Small 

Mainframe 

CICS 

CMS 

DL/1  DOSA^S 

SQL/DS 

VSE 

VM 
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As  a  result  of  this  layering  of  diverse  software  among  different  types  of  main¬ 
frame  systems,  inevitable  incompatibilities  occur  that  ultimately  affect  functionality,  per¬ 
formance,  and  costs.  Attempts  to  overcome  design  shortfalls  or  compatibility  problems 
often  calls  for  introduction  of  conversion  programs  or  software  patches.  Disregarding  the 
maintenance  nightmare  that  these  supplementary  “band-aids”  cause,  the  mainframe  soft¬ 
ware  ultimately  becomes  corrupted  by  fragmentation — with  a  resulting  higher  overhead 
and  greater  inflexibility. 

» 

c.  The  Widening  Gap 

The  three  major  shifts  in  the  computing  environment  and  the  high  costs  and 
labyrinthine  complexity  of  the  mainframe  computing  environment  are  not  the  only  per¬ 
ceived  weaknesses  of  this  fading  monolith.  As  the  mainframe  remains  plagued  by  its  own 
problems,  advances  in  the  personal  computer  market  has  produced  trends  that  the  broad 
market  has  found  quite  appealing.  Certainly,  the  demand  has  increased  for  “user-friendli¬ 
ness,”  graphical  user  interfaces  (GUIs),  object-oriented  programming  (OOP),  fourth-gen¬ 
eration  la.nguage  (4GLs),  and  open  systems.  The  personal  computer  market,  amid  intense 
competition,  has  promptly  responded  to  the  call.  Though  the  mainframe  software  develop¬ 
ers  have  promised  to  deliver  equivalent  or  better  products  in  many  cases,  the  evolution  of 
tho.se  products  has  been  too  slow  to  suit  the  taste  of  the  demanding  user.  Thus,  as  shown  in 
Figure  2,  the  gap  between  the  mainframe  and  popular  alternatives  grows  wider. 

The  Ganner  Group,  a  highly  rated  IS  consulting  firm,  attributes  the  widening 
gap  to  the  following: 

•  Traditional  mainframes  are  too  expensive.  S/390  is  the  target  for  open  .systems, 
Unix,  PCs  and  other  challengers  because  it  is  expensive  compared  to  alternatives 
and  yet  it  still  commands  a  significant  share  of  the  market 

•  MVS  is  perceived  to  be  proprietary  and  more  closed  than  many  other  platforms. 
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User  needs: 


Mainframe  Technology: 


•  Usability 

•  Increasing  Complexity 

♦  Quality 

•  Increasing  Manpower  Costs 

•  Diversity 

•  Low  Quality  of  Solutions 

•  Economy 

•  Limited  Functionality 

Figure  2:  The  Widening  Gap  [Ref.  4:p.  35] _ 

•  The  pace  of  MVS  software  evolution  has  been  slow.  GUIs,  object-oriented  pro¬ 
gramming,  network  processing,  including  client/server,  were  deployed  earlier  on 
non-MVS  platforms.  [Ref.  7:p.  10-1 1] 

d.  The  Mainframe  Bureaucracy 

Best  typified  by  the  image  of  the  “white  coated  men  behind  glass  doors,”  the 
traditional  mainframe’s  pre.sence  is  usually  accompanied  by  excessive  bureaucratic  bag¬ 
gage  that  all  too  often  exacerbates  inefficiencies  and  wasteful  administrative  overhead.  Un¬ 
fortunately,  with  all  of  its  inherent  complexity  in  the  software  and  hardware,  this  team  of 
“experts”  is  not  uncalled  for.  Organizations  have  come  to  accept  this  bureaucratic  burden 
as  a  necessary  evil  to  ensure  task  accomplishment.  The  complexity  of  both  the  hardware 
and  software  (illustrated  earlier)  warrants  system  specialists  with  narrowly  defined  Job  re- 
.sponsibilities.  One  expert  familiar  with  the  costs  of  the  personnel  states: 

...the  human  costs  of  running  the  mainframe  are  as  high  as  its  other  costs.  And  de¬ 
spite  the  high  expenditure  on  what  tries  to  present  itself  as  a  ‘luxury’  product,  one  is 
still  faced  with  inflexibility.  The  human  bureaucracy  in  the  large  mainframe  instal¬ 
lation  actually  adds  to  the  rigidity  inherent  in  the  underlying  system.  [Ref.  4:p.  42] 


The  isolation  of  the  MIS  department  behind  the  glass  house  contributes  to  an 
environment  that  makes  it  easy  for  computer  specialty  ,  to  be  insulated  from  real-world 
business  requirements  and  unresponsive  to  end-users.  Because  of  this  and  already 
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backlogged  application  development  and  maintenance,  new  systems  requirements  often  are 
not  met.  With  the  desktop  technological  advances,  new  development  tools  available,  and 
the  higher  end-user  experience  levels,  the  gap  between  the  mainframe  and  PC  appears  to 
be  widening.  The  market  demand  is  for  GUIs,  4GLs,  and  OOP  among  other  things,  where 
the  desktop  often  exceeds  the  mainframe  in  capabilities.  Organizations  are  realizing  that  the 
mainframe  bureaucracy  is  costly  in  more  than  one  way.  Not  only  are  the  costs  of  maintain¬ 
ing  existing  mainframe  hardware  and  software  high,  but  the  opportunity  costs  of  not  ad¬ 
vancing  with  current  software  trends  are  equally  significant. 

2.  Evolutionary  Changes  Through  Desktop  Computing 

Though  the  mainframe  computer  has  been  the  traditional  computing  architecture 

of  the  past,  the  desktop  revolution  is  charting  a  new  course  for  the  future  of  computing.  The 
rapid  changes  and  availabilities  of  opportunities  is  not  only  overwhelming,  but  also  confus¬ 
ing.  Nonetheless,  the  new-found  power  currently  available  on  the  desktop  has  created  a 
technological  momentum  and  an  array  of  architectural  options  that  is  mind  boggling.  Un¬ 
deniably,  the  trend  has  taken  over  the  industry  and  is  changing  the  way  organizations  are 
coping  with  their  methods  of  processing  information.  This  section  will  analyze  the  charac¬ 
teristics  of  the  desktop  computer  that  have  spurred  this  revolutionary  change,  and  will  ex¬ 
plore  the  evolutionary  IS  architectural  options  and  trends  that  have  resulted  from  it 

a.  Defining  the  Desktop  Computer 

With  the  move  towards  desktop  computing,  it  is  important  to  define  some  re¬ 
lated  terminology  a  little  more  explicitly  for  the  sake  of  clarity.  When  referring  to  desktop 
computing,  this  term  refers  inclusively  to  personal  computers  (PCs)  and  what  are  common¬ 
ly  called  workstations.  Workstations  usually  have  a  true  multitasking  operating  system,  and 
are  accompanied  by  high  resolution  display  cards  and  monitors  and  a  math  coprocessor. 


Workstations  have  also  been  the  machine  of  choice  when  it  conies  to  scientific 


applications.  In  contrast,  PCs  have  commonly  been  the  choice  for  business  purposes. 
Though  these  two  classes  of  computers  are  quickly  merging  together  and  the  differences 
inevitably  are  blurred.  Figure  3  illustrates  a  distinction  that  Gartner  Group  makes  that  may 
be  helpful  in  clarifying  ambiguous  definidons  and  for  understanding  the  differences  (subtle 
and  changing  as  they  may  be)  between  the  PC  and  the  workstation. 


Personal  Computers 

•  Limited  capacity  and  performance 
relative  to  workstations 

•  Intel  CPU 

PC  LAN/NOS  work  group 
connectivity 

•  Primarily  DOS,  Windows,  Mac, 
or  OS/2;  NT  merging 

•  Primarily  in  ject  sales 


Workstations 

Highly  scalable  in  capacity  and 
performance 
Primarily  RISC  CPU 
High-level  peer  connectivity  and 
enterprise  inte^ation 
■  Primarily  a  Unix  environment 
Primarily  direct  sales 


Figure  3:  Piffferences  between  the  PC  and  Workstation  [Ref.  X:p.  1] 
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b.  Perceived  AdvanU^es  with  the  Desktop 

The  pace  of  change  in  desktop  computers  has  been  staggering:  within  the  past 
decade  microcomputers  have  advanced  their  lot  from  being  hobbyists’  toys  to  become  the 
centerpiece  of  computing.  New  and  more  powerful  PC  hardware  and  operating  systems  are 
promising  and  delivering  performance  characteristics,  security  features,  and  multiprocess¬ 
ing  capabilities  that  have  most  often  been  associated  with  minicomputers  and  mainframes. 
Besides  rivaling  performance  features  of  more  traditional  systems,  desktop  computers  are 
al.so  offering  four  key  attributes  often  not  found  with  their  larger  counterparts:  cost  savings, 
desktop  control,  technological  flexibility,  and  responsiveness  to  business  changes 
[Ref.  9:p.  11]. 

( 1 .)  Cost  Savings.  Without  a  doubt,  cost  savings  is  the  biggest  driving  force 
behind  the  de.sktop  revolution.  The  many  suppliers  and  the  resulting  economies  of  scale 
have  produced  an  intensely  competitive  market  with  attractive  promises  of  cost  savings  that 
have  been  irresistible  to  both  small  and  large  businesses.  One  aspect  of  cost  justification 
has  always  been  to  compare  and  analyze  the  hardware’s  price-to-performance  ratios.  For 
example,  the  price  per  MIPS — as  discussed  later,  not  the  best  basis  for  comparison — on  an 
IBM  3()9()-6(K)  mainframe  has  been  quoted  at  $130,000;  at  the  desktop  level,  the  price  per 
MIPS  on  the  RS/6(KK),  IBM’s  RISC  workstation,  is  roughly  $500  [Ref.  6:p.  4]. 

Beyond  this,  the  desktop  computer  market  offers  organizations  cost  savings 
in  many  other  areas.  From  software  development  to  software  maintenance,  desktop  com¬ 
puting  offers  not  only  potentially  huge  savings,  but  also  a  greater  variety  of  options.  In 
terms  of  scalablity,  instead  of  risking  huge  corporate  investments  in  untested  mainframe 
projects,  organizations  may  buy  only  as  much  computing  power  as  they  currently  need. 
Through  the  u.se  of  distributed  networks,  organizations  can  modularly  add  to  their  infra¬ 
structure  as  requirements  dictate.This  added  benefit  manifests  itself  both  when 
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organizations  have  limited  funds  to  invest  in  stait-up  IS  projects  and  when  systems  grow 
older  and  need  to  be  replaced  by  more  capable  technology.  The  architectural  options  pro¬ 
vided  by  networking  and  the  creation  of  distributed  systems  allow  for  the  computing  sys¬ 
tems  to  be  augmented  incrementally,  a  workstation  at  a  time.  Finally,  in  terms  of  personnel, 
great  potential  for  cost  savings  exists  in  terms  of  a  more  productive  work  force  within  a  less 
bureaucratic  environment — a  function  of  greater  desktop  control. 

(2.)  Desktop  Control.  One  of  the  readily  apparent  advantages  of  desktop 
computers  in  a  decentralized  environment  is  that  this  environment  brings  computing  power 
closer  to  the  end-user.  As  such,  there  is  no  longer  as  much  a  dependency  on  the  technicians 
behind  the  “glass  house”  to  solve  logjams  in  the  system.  With  this  greater  degree  of  em¬ 
powerment,  the  more  educated  end-user  can  better  control  the  IS  infrastructure  and  help  an¬ 
ticipate  and  make  changes.  This  customization  of  the  computing  environment  helps  to 
foster  a  greater  sense  of  ownership  among  end-users;  the  increased  motivation  and  involve¬ 
ment  of  users  can  also  increase  overall  productivity. 

Empowerment  at  the  end-user  level  and  subsequent  desktop  control  does  not 
come  merely  through  decentralization.  It  is  also  the  case  that  increasingly  innovative  and 
sophi.sticated  developments  are  taking  place  on  the  desktop  at  a  much  faster  pace  than  at 
the  mainframe  level.  Industry  trends  and  market  dynamics  are  adapting  desktop  computing 
features  to  meet  the  needs  of  their  end-users.  End-users  have  demanded  a  shift  away  from 
the  character-based  interfaces;  the  graphical  user  interface  (GUI)  is  becoming  the  norm. 
End-users  have  sought  technical  flexibility  to  control  their  desktop  interface,  giving  them 
a  standard  “look  and  feel”  that  matches  their  intuition.  The  so  called  WIMP  interface — 
Windows,  Icons,  the  Mouse,  and  Pull-down  menus — is  becoming  the  de  facto  standard. 
Voice  commands  and  handwriting  interfaces  are  currently  making  their  debuts.  Again, 
the.se  trends  are  introduced  and  becoming  standardized  at  the  desktop  level.  Desktop 
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computers,  not  traditional  mainframes  with  dumb  3270  terminals,  represent  the  leading 
edge  and  the  future  in  this  area — a  trend  with  significant  underlying  implications. 

(3.)  Technological  Rexibility.  Technological  flexibility  refers  not  only  to 
the  greater  desktop  control  as  discussed  above,  but  more  so  to  the  variety  of  hardware  and 
software  options  available  in  a  desktop  environment.  The  move  away  from  the  traditional 
mainframe  environment,  often  regarded  as  too  structured,  “stove-piped,"  and  proprietary, 
has  created  a  movement  to  the  other  extreme  at  the  de.sktop  level.  IS  professionals  have  not 
wanted  to  be  locked  in  to  a  monolithic  structured  environment,  so  the  move  has  been  to¬ 
wards  networks  linking  a  host  of  heterogeneous  desktop  hardware  and  software  elements. 
IS  professionals  have  not  wanted  to  be  at  the  mercy  of  one  vendor,  and  their  demands  have 
met  with  a  market-wide  race  towards  development  and  implementation  of  the  almighty 
“open  system.”  End-users  have  not  wanted  to  rely  on  technicians  behind  the  glass  house, 
so  they  have  been  empowered  with  applications  tools  such  as  4GLs  and  other  end-user 
centered  applications.  The  call,  in  short,  has  been  for  technological  flexibility  at  all  levels, 
and  the  desktop  market  has  been  the  first  to  respond  to  the  need. 

(4.)  Responsiveness  to  Business  Change.  This  fourth  attribute  of  desktop 
computing  is  really  an  effect  of  its  greater  cost  savings,  desktop  control,  and  technological 
flexibility.  The  new  challenges  of  the  1990s  have  introduced  new  business  imperatives  that 
demand  technological  flexibility  in  the  IS  infrastructure.  As  organizational  changes  occur 
to  reflect  a  changing  business  environment,  so  too  must  the  IS  infrastructure  adapt  to  effi¬ 
ciently  acconunodate  that  change.  All  too  often,  “information  systems  have  cast  specific- 
ways  of  doing  business  in  concrete,  not  allowing  a  company  to  change  its  operating  proce¬ 
dures  or  move  into  new  lines  of  business  as  quickly  as  management  would  like”  [Ref.  I  :p. 
296].  Thus,  traditionally  centralized  and  inflexible  IS  systems  (most  often  epitomized  by 
the  mainframe)  may  not  only  be  inadequate  in  this  new  environment,  but  could  represent  a 
serious  liability.  Many  believe  desktop  computing,  linked  to  local  and  wide-area  networks 
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to  create  a  heterogenous  distributed  architecture,  provides  a  more  viable  alternative  to  this 
inflexibility.  According  to  one  IT  consulting  group: 

Resources  must  be  capable  of  dynamic  response  to  increasingly  volatile  competitive, 
market,  and  economic  environments.  Moves  toward  a  different  paradigm  of  IS  de¬ 
ployment  has  begun  in  many  organizations...  Increasing  power  and  sophisticated  of 
distributed  computing  systems  provide  one  of  the  elements  of  this  paradigm.  PCs  are 
bringing  more  powei^,  user-Mendly  IS  tools  to  the  individual...  small  systems  and 
servers,  as  well  as  networking  developments  make  it  possible  to  offer  new  types  of 
distributed  solutions.  These  allow  IS  to  be  more  closely  mapped  to  business  process¬ 
es  at  all  organizational  levels  in  order  to  provide  nwre  flexible  and  responsive  tools 
as  business  needs  change.  [Ref.  1 1:p.  I]] 

D.  THE  RESULTING  PARADIGM  SHIFT:  DOWNSIZING 

Inspired  by  the  promises  of  the  desktop  revolution  and  the  opportunities  of  new 
architectures,  there  is  no  doubt  that  IT  is  in  the  midst  of  profound  change.  A  fundamental 
shift  is  occurring  in  the  way  information  is  being  processed,  a  move  that  is  most  often 
described  as  an  exodus  away  from  the  traditional  mainframe  towards  architectures  charac¬ 
terized  by  networks  of  smaller,  heterogeneous  desktop  personal  computers  and  worksta¬ 
tions.  This  trend,  characterized  by  the  shifting  of  processing  from  “big”  systems  to 
“smaller”  systems,  has  been  labelled  “downsizing”  of  information  systems.  Truly  a  para¬ 
digm  shift,  the  new  opportunities  offered  by  heterogeneous  networks  of  powerful  desktop 
computers  forces  IS  professionals  to  re-evaluate  traditional  methodologies  of  processing 
information  in  light  of  new  systems  that  are  governed  by  different  sets  of  rules. 

After  many  years  of  practice,  IS  had  started  to  get  accustomed  to  managing  comput¬ 
ing  on  monolithic  systems.  IT  was  getting  manageable,  problems  somewhat  predictable. 
That  .stability  is  now  being  overthrown  with  the  introduction  of  the  powerful  desktop  and 
distributed,  heterogeneous,  and  more  unmanageable  systems.  The  desktop  computing  en¬ 
vironment  represents  a  radically  different  world  from  its  monolithic  predecessor  with  new 
.software  tools  and  computing  techniques  to  operate  in  a  distributed,  multivendor,  software- 
centric  environment  that  focuses  on  the  end-user.  This  new  form  of  computing  will  have 
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pervasive  effects  that  may  require  organizational  le-thinking  of  traditional  confuting 
methods,  redeployment  computing  resources,  and  re-training  personnel.  IS  professionals 
will  be  forced  to  respond  to  a  whole  new  set  of  management  and  technical  challenges  in 
this  increasingly  complex  environment.  Thus,  while  downsizing  may  offer  a  vast  array  of 
new  opportunities,  this  paradigm  shift  does  not  come  without  an  equal  array  of  barriers  and 
pitfall.s. 

Some  IS  professionals  have  criticized  the  labelling  of  this  movement  as  “downsizing" 
us  too  re.strictive  a  term  and  have  suggested  adoption  of  “rightsizing"  as  a  more  appropriate 
term.  Rightsizing  implies  choosing  the  most  appropriate  computer — regardless  of  size — to 
be.st  suit  an  organization’s  processing  needs.  Another  term,  “smartsizing,"  has  also  been 
commonly  used  with  the  same  connotations  as  rightsizing.  Still,  others  prefer  use  of  the 
term  “upsizing"  to  describe  moving  networked  personal  computers  and  workstations  to  an 
environment  with  more  robust  features.  This  could  imply  actually  moving  to  larger  systems 
or  simply  to  servers  with  better  capabilities  in  areas  such  as  security  and  backup. 

Whatever  the  most  appropriate  term,  there  is  no  doubt  that  increased  processing  pow¬ 
er  at  all  levels  (but  perh2q)s  most  noticeably  at  the  desktop  level)  has  created  the  opportu¬ 
nities  to  think  of  new  ways  of  processing  information.  It  is  necessary,  however,  to  formally 
define  a  vague  term  to  clarify  its  connotations.  For  the  purpose  of  this  thesis,  I  will  adopt 
the  Gartner  Group's  definition  of  downsizing: 

Downsizing  is  the  redeployment  of  information  systems  from  a  traditional  main¬ 
frame  to  a  new  architecture,  with  the  primary  goal  of  reducing  total  IT  expenditures 
across  the  enterprise.  Downsizing  generally  refers  to  the  migration  of  processing 
from  traditional  mainframes  to  less  expensive  alternative  mainframes,  to  midrange 
.systems  for  conventional  application  processing— e.g.,  batch  or  on-line  transaction 
processing  (OLTP) — or  to  LAN-based  networks  of  midrange  and  PC-based  servers. 
[Ref.  12:p.  4) 

Three  es.sential  ingredients  contribute  and  fuel  the  downsizing  trend:  recognition  of 
information  as  a  strategic  asset,  realization  that  the  computing  architecture  is  the  essential 
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means  of  defining  an  organization’s  “information  strategy,”  and  the  belief  that  the  promises 
of  smaller,  increasingly  powerful  computers  are  the  key  to  fulfilling  that  information  strat¬ 
egy.  In  short,  many  CIOs  have  seen  the  “writing  on  the  wall"  and  are  embarking  on  this  new 
voyage.  Because  technology  is  changing  so  rapidly,  no  one  can  be  certain  where  the  “voy¬ 
age”  will  end.  What  has  become  too  apparent  to  most  organizations,  however,  is  that  the 
future  is  away  from  the  traditional  mainframe — and  organizations  are  getting  on  the  down¬ 
sizing  train  as  soon  as  possible  before  it  is  too  late. 

One  recent  downsizing  survey  conducted  by  the  Gartner  Group  at  their  Midrange 
Computing  Strategies  (MCS)  Conference  polled  attendees  about  their  downsizing  plans. 
The  respondents  represented  U.S.  corporations  with  a  total  data  processing  budget  of  close 
to  $5  billion.  Indications  of  the  strength  of  this  paradigm  shift  are  evident  in  the  results: 

•  74  percent  of  the  respondents  indicated  that  they  downsized  applications  in  1993. 

•  %  percent  indicated  they  were  planning  to  downsize  in  1994  or  1995 

•  To  contrast  this  with  previous  trends,  only  60  percent  of  those  surveyed  in  1992 
indicated  that  they  were  planning  or  implementing  a  downsizing  project. 
[Ref.  13:p.6] 
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III.  ESTABLISHING  THE  APPROPRIATE  ARCHITECTURE 


The  previous  chapter  discussed  the  more  traditional  roles  that  the  mainframe  and  PC 
have  played  in  organizadons.As  the  term  “rightsizing”  implies,  however,  the  downsizing 
paradigm  shift  does  not  necessarily  entail  establishing  an  architecture  limited  to  the  central¬ 
ized  mainframe  architecture  or  one  that  is  exclusively  built  around  a  network  of  desktop 
computers.  Computing  components  can  be  bought,  but  a  computing  architecture  must  be 
built  to  optimize  processing  capabilities.  Processing  power  does  not  necessarily  have  to  be 
the  mere  sum  of  its  individual  computing  components.  New  architectural  tools  are  helping 
to  synthesize  disparate  computing  components  and  are  enabling  more  effective  and  efti- 
cient  fomts  of  processing.  Indeed,  the  momentum  that  has  been  driven  by  technological  ad¬ 
vances  has  unharnessed  traditional  mindsets  and  unleased  new  architectural  ideas.  This 
chapter  will  discuss  those  new  architectural  choices  and  die  tools  that  serve  as  their  building 
blocks.  A  final  section  will  discuss  migration  strategies  for  migrating  from  traditionally 
centralized  mainframe  architectures  to  client/server  type  environments. 

A.  ARCHITECTURAL  DECISIONS 

Before  the  advent  of  the  powerful  desktop  personal  computers  in  the  19M0’s,  almost 
all  computers  performed  batch  and  on-line  processing  on  the  traditional  mainframe  with  the 
aid  of  “dumb”  terminals.  The  glory  days  of  the  mainframe  and  its  future  faded  dramatically 
with  the  introduction  of  the  personal  computer.  Innovative  technology  over  the  years  has 
enabled  today's  networked  desktop  computers  with  processing  capabilities  that  claim  to  ri¬ 
val  those  of  the  older,  monolithic  host  platforms.  Besides  impressive  performance  mea¬ 
sures,  desktop  computing  now  offers  the  advantage  of  user-friendly  features  such  as 
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intuitive  graphical  user  interfaces  (GUI’s)  on  a  platform  much  closer  to  the  user — for  what 
lirst  appears  to  be  at  a  vastly  more  cost-efiicient  price. 

Developing  architectures,  however,  do  not  necessarily  force  IS  departments  into  an 
either/or  decision  between  mainframes  and  networked  desktop  systems.  New  architectures, 
such  as  client/server,  are  helping  break  the  established  boundaries  of  IS  and  are  allowing 
platforms  to  take  advantage  of  mutual  processing  capabilities  and  exploit  each  other’s 
strengths.  More  flexible  architectures,  that  include  integration  of  current  systems  into  new 
architectures,  are  helping  organizations  respond  to  an  increasingly  global  and  competitive 
environment  in  new  and  more  effective  ways. 

1.  The  Client/server  Model 

The  client/server  model,  perhaps  the  most  important  architectural  by-product  of 
the  downsizing  trend,  was  developed  as  a  direct  result  of  the  increasing  power  and  decreas¬ 
ing  costs  of  desktop  systems.  Simply  put,  the  objective  of  clieni/server  is  to  maximize  ef¬ 
ficiency  and  effectiveness  of  computing  resources  by  allowing  various  elements  to 
specialize  at  what  they  do  best. 

One  of  the  most  pervasive  new  trends  currently  dominating  the  IS  world,  client- 
server  is  a  term  that  is  quickly  becoming  an  industry  buzzword  to  describe  the  new  move¬ 
ment  in  distributed  computing.  Like  so  many  buzzwords,  however,  the  term  client/server 
has  been  used  so  often  and  in  so  many  different  contexts  that  it  has  come  to  mean  different 
things  to  different  people.  With  so  many  degrees  of  distributed  computing  and  varieties  of 
implementation,  the  terminology  associated  with  client/server  has  become  somewhat 
confusing. 

It  appears  that  there  are  two  schools  of  thought  in  this  area.  One  school  uses  the 
terms  distributed  computing,  cooperative  processing,  and  client/server  loosely  and  inter¬ 
changeably  to  describe  the  client/server  architecture,  while  the  other  tries  to  define 
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technical  and  semantic  differences  between  the  three.  In  general,  however,  most  IT  profes¬ 
sionals  would  probably  agree  that  client/server  computing  is  a  form  of  distributed  comput¬ 
ing  and  involves  a  degree  of  cooperative  processing.  Indeed,  one  IS  professional  tries  to 
clarify  the  terminology  with  the  following  assertion; 


A  distributed  system  is  defined  as  a  computing  environment  in  which  processes  and/ 
or  data  are  distributed  throughout  an  organization  with  the  requirement  that  a  degree 
of  interaction  between  systems  is  required  to  complete  processing  the  workload.  It  is 
to  this  category  that  the  term  client/server  relates.  There  is  no  particular  signifi¬ 
cance  (other  than  semantic)  in  distinguishing  client/server  from  distributed  systems. 
[Ref.  14:p.  32] 


The  client/server  term  essentially  tries  to  add  a  little  more  precision  to  the  above 
definition  of  distributed  systems  by  defining  the  specific  roles  of  computers  within  a  dis¬ 
tributed  environment.  Again,  however,  IT  professionals  have  trouble  standardizing  this 
term;  one  Chief  Executive  Officer  of  a  mainframe  software  company  believes  “client/serv¬ 
er  is  a  term  that  has  been  overused  and  is  confusing  customers  because  different  people  are 
using  it  in  different  ways”  [Ref.  15].  Most  IS  professionals  agree  that  the  architecture  splits 
up  the  processing  between  a  client,  usually  a  desktop,  and  a  back-end  server.  The  degree  to 
which  the  processing  is  split  up  is  where  the  deHnition  becomes  vague.  Typical  definitions 
of  client/server  resemble  that  given  by  a  well-known  IS  consultant: 


Client/server  architecture  splits  an  application  into  a  front-end  client  component  and 
a  back-end  server  component.  On  ^e  front  end,  the  client  part  of  the  application, 
running  on  a  workstation,  gathers  data  from  the  user,  prepares  it  for  the  server,  and 
issues  a  request  to  the  server.  On  the  back  end,  the  server  waits  for  requests  from  its 
clients.  When  it  receives  a  request,  the  server  processes  it  and  returns  the  requested 
information  to  the  client.  The  client  then  presents  the  data  to  the  user  through  its  own 
interface.  [Ref.  16] 

This  definition  is  somewhat  incomplete.  A  more  comprehensive  definition  would 
include  a  discussion  of  the  client  and  server  roles  in  data  presentation,  application  location, 
and  data  management.  The  Gartner  Group  con.sulting  service,  recognizing  the  varying 
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degrees  of  client/server  uses  Hgure  4  to  illustrate  the  different  models  and  “shades”  of  cli¬ 
ent/server  computing: 
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(Source:  Gartner  Group) 
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Figure  4;  Variations  in  Client/Server  Definitions  [Ref.  9] 


•  Distributed  Presentation:  Also  known  as  “screen  scraping,”  the  programmable 
workstation  (client)  is  run  by  a  host  (server)  based  application  that  alters  the  dull 
3270  character-based  format  to  a  more  friendly  GUI  interface.  Additionally,  the 
workstation  is  prompted  by  the  host  to  collect  user  inputs  (using  the  GUI  format) 
and  interact  with  the  host  Some  IS  professionals  do  not  regard  this  or  the  remote 
presentation  (see  next  paragraph)  as  “true”  client/server. 

•  Remote  Presentation:  Again,  the  desktop  workstation  acts  like  a  client  in  this  situ¬ 
ation.  In  this  case,  the  desktop  runs  a  presentation  application  capable  of  receiving 
messages  from  the  host-based  server  and  is  able  to  utilize  more  involved  GUI  fea¬ 
tures  such  as  menus,  windows,  and  dialog  boxes. 

•  Distributed  Function:  Commonly  referred  to  as  the  “peer-to-peer”  model,  the  tri¬ 
plication  is  split  between  the  between  the  desktop  and  the  host  (not  necessarily  a 
mainframe),  with  each  acting  as  the  client  (requester)  or  server  (provider)  at  vari¬ 
ous  times.  I^ocessing  may  occur  concurrently  on  both  platforms,  with  control  of 
the  application  also  shifting  between  the  different  nodes. 

•  Remote  Data  Management:  In  tiiis  case,  the  ^plication  wholly  resides  on  and  is 
driven  by  the  desktop  computer  acting  as  the  client  The  client  submits  data  queries 
or  updates  to  the  server,  which  responds  to  the  request 


•  Distributed  Database:  The  presentation  functions,  i^)plication,  and  sonic  data 
management  reside  on  the  desktop  computer  (client).  (Queries  are  submitted,  as 
necessa^,  to  the  server.  Here,  data  may  be  distributed  on  multiple  nodes  through¬ 
out  the  infrastructure.  [Ref.  9] 

Thus,  it  becomes  more  clear  that  the  variance  in  IS  professionals’  definitions  of 
the  client/server  model  occurs  as  a  result  of  the  varying  degrees  of  recognition  of  client  and 
server  responsibilities.  One  Computerworld  survey  reveals  this  disparity  of  IS  profession¬ 
als’  definitions  of  client/server  and  illustrates  how  their  definitions  differ  directly  with  the 
perceived  processing  roles  of  the  client  and  the  server.  The  survey  was  based  on  the  re¬ 
sponses  of  2 1 9  informations  systems  professionals  who  run  applications  in  the  client/server 


environment.  The  following  results  were  obtained: 

Table  3:  ‘‘HOW  ARE  YOU  DEFINING  CLIENT/SERVER?”  [Ref.  17:p.  8] 
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Client 
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Client 

Presentation 

Presentation 
and  some  busi¬ 
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Presentation 
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Presentation 
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Server 

Server 

Server 

Server 

Server 

Everything 

else 
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and  some  dis¬ 
tributed  sys¬ 
tems 

Additional 
logic,  data 
management 
and  fully  dis- 
trbuted  sys¬ 
tems 

Data  manage¬ 
ment 

Don’t  know 

With  four  almost  equally  divided  definitions,  the  survey  effectively  illustrates  the 
disparate  perspectives  of  the  client/server  paradigm  and  helps  explain  some  of  the  customer 
confusion.  At  a  minimum,  however,  the  survey  in  Table  3  indicates  that  all  IS  professionals 
at  least  agree  that  the  GUI  interfaces  of  the  intelligent  desktop  make  it  the  platform  most 
capable  of  handling  the  presentation  functions.  At  the  other  extreme,  many  organizations 
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prefer  that  the  client  handle  not  only  the  presentation-related  processing,  but  most — if  not 
all — of  the  application  logic.  [Ref.  17:p.  8] 

Despite  the  varying  opinions  of  where  the  processing  takes  place,  what  is  clear  is 
that  many  organizations  readily  recognize  the  potential  benefits  of  the  architecture.  As  DoD 
and  corporations  reengineer  and  redesign  their  organizational  structure  and  information 
processes,  IS  structures  are  reevaluated  and  realigned  in  accordance  with  strategic  and  tac¬ 
tical  objectives.  Client/server  is  often  argued  to  be  the  most  logical  means  of  realigning  the 
IS  architecture  because  it  exploits  the  same  perceived  advantages  of  desktop  computing 
(such  as  the  reduced  hardware  and  software  costs  with  increasingly  powerful  performance 
capabilities — as  described  in  the  previous  chapter)  while  creating  an  environment  that  is  re¬ 
sponsive  to  b:isiness  needs.  Other  unique  and  commonly  cited  client/server’s  advantages 
include: 

•  System  flexibility:  The  inrreasing  standardization  of  protocols  and  “open  sys¬ 
tems”  permits  ad-hoc  integration  of  disparate  platforms.  As  requirements  change, 
the  client/server  architecture  provides  for  the  easy  integration  of  additional  nodes. 
Furthermore,  IS  departments  can  integrate  old  technology  with  new  technology — 
utilizing  sunk  investments  instead  of  jettisoning  old  equipment  In  this  sense,  the 
client/server  methodology  can  be  implement^  in  a  non-disruptive,  self-paced, 
manner. 

•  User-centricity:  Applications  development  tools  (e.g.  4GL’s)  and  data  manipula¬ 
tion  methods  focus  on  the  user.  For  example,  a  user’s  database  query  is  resiwnded 
to,  theoretically,  with  “seamlessness.”  Physical  location  of  application  or  data  is 
not  pertinent. 

•  Vendor  independence:  Client/server  unleashes  IS  departments  fi-om  the  depen¬ 
dence  on  vendors’  proprietary  hardware  and  software.  As  more  protocols  and  sys¬ 
tems  truly  become  standardized  and  open,  users  can  select  the  “best  of  breed” — 
the  system  that  provides  the  desired  functionality  for  the  least  price. 

•  Reliability:  Though  one  machine  may  go  down,  in  a  client/server  environment 
there  is  enough  r^undancy  and  machine  independence  to  allow  the  business  to 
continue  normal  operations. 

Despite  the  disproportionate  focus  on  the  personal  desktop  computer  in  client/ 
server,  the  mainframe  and  minicomputer  can  also  play  important  and  needed  roles  in  this 
architecture.  Many  organizations  have  been  either  strictly  PC-centric  or  mainftame-centric; 
client/server  offers  a  blend.  As  suggested  earlier,  client/server  is  a  flexible  architecture  that 
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allows  for  the  integration  of  current  systems  in  a  distributed  environment  Mainframe  and 
minicomputers  still  have  many  desirable  characteristics  that  workstations  will  have  diffi¬ 
culty  matching. 

2.  The  Nevv  Role  of  the  Mainframe 

Many  IS  professionals  believe  that  the  move  toward  client/server  need  not  ex¬ 
clude  the  mainframe.  Distributed  computing  can  mean  that  new  technologies  can  supple¬ 
ment  rather  than  displace  older  ones.  With  the  client/server  model,  a  network  composed  of 
main  unes  (to  include  mid-range  computers)  and  powerful  desktop  computers  can  all  play 
critical  roles.  Performance  can  be  optimized  by  the  shifting  and  redeployment  of  data  re¬ 
sources  and  computing  power  according  to  task  requirements  and  system  strengths.  Many 
IS  consulting  groups  believe  that  the  mainframe’s  role  will  evolve  this  decade  in  new  ways 
that  are  synergistic  with  the  boom  in  distributed  computing.  Taking  advantage  of  the  main¬ 
frame  strengths  and  the  current  trends,  they  generally  agree  that  the  future  of  mainframe 
computing  will  be  as  an  enterprise  hub  with  central  roles  in  the  areas  of  data  management 
and  networking  management 

a.  Data  Management  Hub 

Data  management  has  always  been  a  core  strength  of  the  mainframe.  With  the 
mainframe  hardware,  operating  system,  and  software  optimized  for  management  and 
movement  of  large  volumes  of  data,  the  mainframe  has  been  commonly  selected  as  the  cor¬ 
porate  hub  for  mission-critical  applications.  Because  of  these  sophisticated  data  handling 
capabilities  and  the  lack  of  feasible  alternatives,  the  mainframe  has  historically 
dominated — and  consequently  saturated — ^the  data  management  market  with  its  systems 
and  applications. 
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Some  estimate  that  corporations  around  the  world  have  spent  over  $750  bil¬ 
lion  on  software  applications  for  IBM  and  IBM-compatible  mainframes  alone. 
Furthermore,  the  performance  capabilities  of  the  mainframe  are  increasing  at  an  impressive 
rate  along  with  the  desktop.  According  to  one  report,  the  aggregate  number  of  MIPS  on 
mainframes  almost  tripled  between  1988  and  1991  to  firom  about  125,000  to  about  364,000. 
[Ref.  18;p.  29]  Some  believe,  however,  that  this  maiicet  base  and  performance  lead  will 
slowly  be  eroded  by  product  developments  that  offer  high-performance,  low  cost  alterna¬ 
tives  that  can  potentially  rival  the  mainframe.  MIPS  capacity  on  the  desktop,  for  example, 
grew  much  more  than  three  times  during  that  same  period,  thus  reducing  the  mainframe’s 
relative  capacity.  This  trend  is  likely  to  continue — some  absolute  growth  in  maiitframe  ca¬ 
pacity,  but  an  erosion  in  its  relative  lead.  Unless  alternative  platforms  can  prove  to  be  sig¬ 
nificantly  more  cost-effective  though,  the  mainframe’s  role  in  data  management  is  unlikely 
to  change  drantatically  in  the  near  future.  According  to  the  Gartner  Group,  the  “MVS/390 
is  the  logical  candidate  for  the  central  data  server  and  as  a  platform  for  data  warehousing. 
After  all,  it  is  home  to  the  bulk  of  enterprise  production  data  today,  and  therefore  it  involves 
no  effort  to  leave  the  data  there”  [Ref.  7;p.  26]. 

b.  Network  Management  Hub 

The  distributed  computing  environment,  current  lack  of  uniform  network 
standards,  and  increasing  transaction  volume  has  increased  the  burden  and  complexity  as¬ 
sociated  with  managing  multiple  and  diverse  local  area  networks  (LANs).  Managing  these 
LANS  separately  is  difficult  and  costly.  Given  its  track  record  and  promise  of  more  pow¬ 
erful  mainframes,  IS  professionals  believe  that  the  mainframe’s  current  network  manage¬ 
ment  role  can  be  extended  to  service  the  other  types  of  networks  (see  Figure  5). 


Currently,  IBM’s  MVS  widely  serves  as  a  management  hub  for  its  existing 
proprietary  Systems  Network  Architecture  (SNA).  In  addition,  SNA  backbones  are  used  to 
carry  other  LAN  traffic  throughout  the  enterprise.  Expanding  its  role  as  a  management  hub 
to  other  standards-based  systems  that  are  growing  in  this  heterogeneous  environment  (e.g., 
TCP/IP,  NetWare  and  IPX/SPX)  is  a  logical  extension  to  its  current  role.  Managing  the  net¬ 
works  from  one  central  mainframe  would  reduce  complexity  and  redundancy  by  consoli¬ 
dating  monitoring  and  management  of  the  systems.  Because  it  is  already  often  used  as  a 
focal  point  for  communications  switching  and  is  built  to  provide  high  bandwidth,  the  main¬ 
frame’s  role  and  capabilities  make  it  a  suitable  and  appealing  choice  in  the  client/server 
environment 

Other  essential  features  that  a  network  management  hub  must  guarantee  are 
data  security  and  back-up.  Ensuring  that  mission-critical  data  are  secure  and  backed-up  be¬ 
comes  signifrcantly  more  difficult  as  the  numbers  and  diversity  of  LANs  increase.  Using 
its  sophisticated  security  mechanisms  and  storage  management  the  mainfrrame  can  act  as  a 
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central  managennent  point  to  ensure  that  only  authorized  users  can  access  dispersed  data¬ 
bases  and  that  those  databases  themselves  are  intact 

B.  ARCHITECTURAL  BUILDING  BLOCKS 

As  important  as  the  new  architectures  themselves  are  the  tools  needed  to  design,  de¬ 
velop,  implement  and  maintain  those  architectures.  The  technological  advances  in  desktop 
hardware  have  not  come  without  equivalent  advances  in  related  software.  From  increasing¬ 
ly  more  powerful  operating  systems  to  new  software  development  approaches,  die  desktop 
computer  continues  to  rapidly  progress  with  impressive  innovations.  Software  developo's, 
driven  by  sheer  number  of  PCs  and  the  resulting  huge  demand  for  related  software  prod¬ 
ucts,  are  responding  with  quick  delivery  of  new  and  inexpensive  software  products  to  meet 
changing  business  needs  and  architectural  requirements.  The  high  volume/  low  price  mar¬ 
ket  of  desktop  software  is  accelerating  greato'  progress  and  innovation  of  software  products 
than  is  possible  in  the  low  volume/high  price  mainframe  software  market  The  low  prices 
of  software  packages  and  innovation  of  software  tools  can,  by  themselves,  make  downsiz¬ 
ing  to  smaller  systems  a  very  attractive  option.  This  section  will  briefly  discuss  those  soft¬ 
ware  building  blocks  that  help  build  architectures  like  client/server — and  provide 
additional  momentum  for  the  downsizing  trend. 

1.  Increasingly  Sophisticated  Operating  Systems 

As  the  desktop  computing  has  evolved  to  play  a  more  central  role  in  corporate 
computing,  their  operating  systems  have  simultaneously  advanced  to  run  more  complex  ap¬ 
plications  and  assume  new  duties  that  had  been  ^ically  relegated  to  larger  systems.  Not 
satisfied  with  the  PC  only  playing  the  word  processor  and  spreadsheet  roles,  vendors  have 
upgraded  the  technological  capabilities  to  provide  a  robustness  that  had  long  been  integrat¬ 
ed  into  the  minicomputer  and  mainframe. 


37 


Cuirently,  the  more  powerful  32-bit  operating  systems  that  are  most  competitive 
within  the  client/server  market  include  UNIX,  OS/2,  and  Windows  NT.  Offering  true  mul¬ 
titasking,  multithreading,  and  multiprocessing,  these  systems  can  tap  the  power  of  386, 
486,  Pentium,  and  PowerPC  microprocessors  and  support  applications  with  32-bit  address 
space  capabilities.  According  to  Gartner  Group,  “current  PC  operating  systems,  such  as 
Windows  NT,  bear  more  resemblance  to  VMS  (or  even  MVS)  than  they  do  their  ancestors 
(e.g.,  DOS)  by  implementing  virtual  memory,  multiprogramming,  pre-emptive  multitask¬ 
ing,  32-bit  addressing  and  symmetric  multiprocessing”  [Ref.  7:  p.  7].  Designed  to  support 
the  burgeoning  distributed  computing  environment,  these  operating  systems  not  only  en¬ 
able  cooperative  processing  over  multiple  systems,  but  also  can  provide  a  degree  of  data 
and  networking  integrity  and  security.  Impressive  systems  management  functions  and  pro¬ 
ductivity  tools  for  applications  developers  make  the  operating  systems  extremely  attractive 
in  the  client/server  architecture. 

With  the  wide  variety  of  competing  operating  systems,  a  major  question  for 
downsizing  corporations  is  which  one  will  be  the  desktop  OS  of  the  future?  (Currently,  Mi¬ 
crosoft  Windows  and  Unix  appear  to  be  dominating  the  market,  with  Windows  NT  posi¬ 
tioning  itself  to  gain  a  large  part  of  the  market  share.  Windows  NT  is  trying  to  accomplish 
what  Unix  attempted  a  decade  ago  by  providing  a  portable  operating  system  across  differ¬ 
ent  hardware  architectures.  Microsoft,  however,  is  going  a  step  farther  by  attempting  to 
provide  a  comprehensive  set  of  standards  with  its  WIN32  based  operating  system,  GUI  ap¬ 
plication  programming  interfaces  (APIs),  applications,  DBMSs,  languages  and  Windows 
Open  Services  Architecture  (WOSA)  interoperability  features  [Ref.  7:p.  45].  Although 
Windows  NT  and  Unix  are  certain  to  survive  any  operating  system  “war”  and  are  likely  to 
be  formidable  players  in  the  future,  it  is  also  likely  that  other  alternatives  will  remain  strong 
market  competitors.  As  such,  trying  to  predict  an  “OS  of  the  future”  to  use  as  a  basis  for 
establishing  a  computer  architecture  is  neither  an  appropriate  or  fruitful  exercise. 
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2.  Graphical  User  Interfaces  (GUIs) 

Another  manifestation  of  the  increasing  sophistication  of  the  operating  systems 
are  the  impressive  graphical  user  interfaces  (GUIs)  that  they  support  The  GUI  interfaces 
available  for  the  different  hardware  platforms  and  operating  systems  are  becoming  more 
standardized;  the  major  GUI  interfaces  outlined  in  Figure  6. 
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Figure  6:  M^jor  GUI  Interfaces 

Providing  a  consistent  seamless,  interface  for  client/server  related  applications 
and  services,  GUIs  are  replacing  traditional  character-based  user  interfaces  that  are  acting 
as  a  client  front-ends.  The  consistent  screens  and  menus  help  create  a  familiar  and  easy-to- 
use  “look  and  feel”  that  helps  to  mask  the  complexity  and  heterogeneity  of  the  clieni/sCTver 
architecture  from  the  end-user.  GUIs  help  empower  the  end-user,  allowing  more  intuitive 
screens  that  allow  easy  retrieval  and  manipulation  of  corporate  data — reducing  training 
time  and  expense  while  also  boosting  productivity. 


3.  Database  Management  Systems  (DBMSs) 

Once  the  responsibility  of  application  programs,  the  role  of  managing  and  inte¬ 
grating  mission-critical  data  spread  throughout  a  distributed  environment  is  now  the  job  of 
increasingly  sophisticated  database  management  systems.  Based  on  the  relational  data 
model  and  the  Structured  C^ery  Language  (SQL),  current  DBMSs  are  able  to  select  and 
combine  diverse  data  elements  located  in  diverse  and  different  systems.  In  typical 
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configurations,  the  data  management  logic  resides  in  the  server  and  the  applications  while 
control  logic  remains  in  the  client  Sharing  processes  and  exchanging  information  seam¬ 
lessly  from  an  easy-to-use  client  interface  is  critical  to  the  DBMS.  Advances  in  DBMS 
technology  allow  some  systems  to  retrieve  and  change  data  in  multiple  database  servers. 

Two  problems  that  have  hindered  more  rapid  progress  of  DBMS’  and  total  inte¬ 
gration  of  all  databases  are  (1)  different  SQL  standards  resulting  in  incompatibility  prob¬ 
lems  and  (2)  legacy  data  that  are  stored  in  non-relational  files.  Tools  have  been  developed, 
however,  to  access  and  translate  data  resident  in  diese  platforms: 

...front-end  tools  such  as  Information  Builders’  Enterprise  Data  Access  (EDA)/SQL 
are  making  possible  end-user  access  to  legacy  data.  These  SQL  front-end  software 
products  and  real-time  language  interpretations  enable  restructuring  in  relational 
terms  of  legacy  data  for  knowl^ge  workers  and  make  real  the  promise  of  universal 
data  access...  EDA/SQL  provides  data  access  to  more  than  SO  different  data  sources 
and  file  structures  on  over  35  disparate  hardware  platforms.  [Ref.  19:p.  1 1] 

4.  Middleware 

Heterogeneous,  distributed  architectures  such  as  client/server  require  interopera¬ 
bility  across  dissimilar  operating  systems,  conununication  protocols,  and  databases.  Mid¬ 
dleware  is  the  enabling  layer  of  software  that  accomplishes  this.  Residing  between  the 
business  application  itself  and  the  network  infrastructure,  the  goal  of  middleware  is  to  unite 
independent  local  operating  systems  and  transform  them  into  a  structure  that  creates  the  il¬ 
lusion  of  being  part  of  a  single,  monolithic  system.  Also  nicknamed  “glueware,”  this  soft¬ 
ware  establishes  virtual  connections  across  hardware  boundaries,  “gluing”  together 
multiple  users,  workstations,  application  programs,  CPUs,  operating  systems,  network  pro¬ 
tocols,  file  systems,  and  other  resources.  A  more  precise  Gartner  Group  definition  is: 


The  layer  of  software  between  the  end-user  application  code  and  the  operating  sys¬ 
tem.  Examples  include  DBMSs,  UIEs  (User  Interface  Environments)  and  TP  (Trans¬ 
action  Processing)  monitors.  The  end-user  application  invokes  middleware  services 
via  APIs  (Application  Programming  Interfaces),  and  sometimes  invokes  operating 
system  services  via  different  APIs.  A  middleware  component  (which  is  merely  an 
operating  system  application)  also  uses  an  API  to  call  for  operating  system  services. 
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In  a  typical  IS  application  of  the  1990s,  the  less  frequent  of  the  three  cases  is  the  one 
where  application  programs  directly  invoke  op^ting  systems  without  passing 
through  a  middleware  component  [Ref.  20:p.  10] 


A  difficult  concept  to  define  precisely,  it  is  helpful  to  examine  what  middleware 
is  ultimately  trying  to  achieve.  Simply  put  middleware  allows  one  procedure  to  locate  an¬ 
other  procedure  anywhere  on  the  network  and  exchange  messages  and  information.  This 
exchange  is  permitted  to  occur  between  sender  and  receiver  regardless  of  physically 
separate  locations,  underlying  corrununication  protocols,  and  different  operating  systems. 
In  accomplishing  this  objective,  middleware  is  also  expected  to  provide  the  ancillary  ser¬ 
vices  of  data  management  presentation,  communication,  and  management  services  dq)ict- 
ed  in  Hgure  7. 


Applicarion^M 
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Figure  7;  Middleware  for  Network  Computing  [Ref.  7:p.  9] 
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Organizations  such  as  the  Open  Software  Foundation  (OSF)  have  helped  to 
standardize  some  of  the  middleware  services  dnough  establishment  of  models  such  as  the 
Distributed  Computing  Enviroiunent  (DCE).  The  middleware  goal,  to  obtain  a  virtuaUy 
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homogeneous  architecture  through  a  system  of  tranq>arent  software  services,  still  remains, 
however,  to  be  the  greatest  chaUenge  of  client/server  and  distributed  computing. 

5.  Application  Development  Tools 

Many  transaction  processing  and  management  information  needs  are  not  being 
met  in  the  current  mainbrame  environment  for  the  simple  reason  that  the  cost  of  providing 
software  to  meet  new  requirements  is  too  high.  The  high  expenses  result  not  only  from 
software  development,  but  also  from  the  need  to  maintain  applications  as  market  and  busi¬ 
ness  requirements  shift.  The  consequential  application  development  backlog  has  encour¬ 
aged  developers  to  seek  relief  through  other  avenues.  The  downsized  environment,  many 
believe,  offers  viable  alternatives  through  both  the  cost-effective  purchase  of  increasingly 
sophisticated  off-the-shelf  packages  and  new  software  development  methodologies  and 
tools.  This  subchapter  will  highlight  the  impact  of  some  of  the  new  methodologies  and  tools 
to  include  the  notion  of  rapid  application  development  (RAD),  4GLs,  and  CASE  tools. 

a.  RapM  AppUcadon  Development 

Rapid  application  development  (RAD)  is  a  term  that  encapsulates  the  trend  in 
software  development  that  digresses  from  the  classic  style  of  software  development — best 
epitomized  by  the  “waterfall”  model — ^towards  a  methodology  that  dramatically  acceler¬ 
ates  delivery  of  software.  The  problem  with  the  classic  methodologies  like  the  waterfall  is 
that  the  process  requires  comprehensive  designs,  formal  reviews,  and  cumbersome  docu¬ 
mentation  that  often  tie  down  progress  in  bureaucratic  inefficiencies.  RAD  techniques  dis¬ 
courage  this  bureaucracy  by  eliminating  formality  and  exhaustive  reviews  and  encouraging 
constant  developer  and  end-user  feedback  as  the  system  is  being  written.  RAD  methodol¬ 
ogies  include  prototyping  and  incremental  development 
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Prototyping,  according  to  some  experts,  is  used  for  the  purposes  of  user  inter¬ 
face  design,  performance  modelling,  and  assessment  of  functionality  [Ref.  6:p.  229].  When 
developing  a  product,  it  is  difficult  for  programmers  to  accurately  assess  end-user  needs 
and  requirements  and  determine  realistic  system  performance  measures.  By  modelling  ini¬ 
tial  designs  to  the  end-user,  developers  can  rapidly  determine  errors  due  to  misinterpreta¬ 
tion  and  miscommunication  and  can  also  establish  initial  system  performance  benchmarks. 
Because  of  highly  productive  prototyping  tools,  new  versions  that  more  accurately  meet 
end-user  needs  can  be  built  According  to  one  IT  consultant  this  process  “accelerates 
failure” — developers  can  build  application  prototypes  far  faster  and  at  far  lower  cost  than 
they  could  on  the  mainframe,  giving  them  the  luxury  of  building  multiple  prototypes  until 
they  find  one  that  works  best  [Ref.  21]. 

Incremental  development  is  different  than  prototyping  in  several  ways.  In  this 
methodology,  developers  build  and  deliver  only  part  of  a  system  at  a  time.  As  end-users 
identify  a  requirement,  developers  design,  program,  test  and  implement  it  as  rapidly  as 
practical.  In  this  fashion,  end-users  have  the  ability  to  gain  the  functionality  of  system  very 
quickly.  This  methodology  can  only  work  in  systems  that  do  not  need  to  be  implemented 
as  an  integrated  product 

b.  Fourth  Generation  Languages  (4GLs) 

One  tool  that  plays  an  integral  part  of  the  downsized  environment,  alleviating 
the  application  backlog  of  the  end-user  and  enabling  RAD  technology,  is  the  4GL.  4GLs 
empower  developers  by  providing  an  engine  that  automatically  generates  program  code  for 
both  application  screens  and  program  logic.  Because  of  these  sophisticated  capabilities  that 
are  sometimes  easy  enough  for  the  end-user  to  understand  and  utilize,  4GLs  have  even  been 
touted  by  some  as  the  panacea  for  the  slow  pace  and  high  expense  of  application 
development 
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According  to  Gartner  Group,  4GLs  can  be  classified  into  three  types;  “front- 
ware,”  database-linked,  and  database  independent  Frontware  4GLs  empower  users  by 
adding  the  capability  of  rapidly  generating  front-end  GUIs  on  the  client-end  to  access  leg¬ 
acy  data.  Frontware  4GLs  depend  on  middleware  to  access  the  data  and  handle  resolution 
of  all  software  linkages.  In  contrast  a  database-independent  4GL  also  requires  middle¬ 
ware,  but  not  to  the  full  extent  that  a  frontware  4GL  does.  A  database-independent  needs 
middleware  primarily  to  help  establish  communication  links  and  access  to  the  database.  A 
database-linked  4GL  is  different  than  a  database  independent  4GL  in  that  the  application 
development  tool  dynamically  creates  links  to  existing  databases.  In  other  words,  the  mid¬ 
dleware  component  is  built  into  the  4GL  application  development  environment.  In  the  cli¬ 
ent/server  environment  where  the  mainframe  maintains  a  role  as  a  data  server,  all  of  these 
4GLs  can  play  an  important  function  in  extending  the  life  of  the  mainframe.  As  new  pro¬ 
cessing  requirements  and  information  needs  shift,  4GLs  can  play  an  important  role  in  re¬ 
sponding  to  changing  business  requirements.  [Ref.  22;p.  2) 

Some  critics  downplay  the  significance  of  4GL  technology.  Although  they  ac¬ 
knowledge  some  4GLs  offer  signifrcant  benefits,  they  also  believe  4GLs  are  generally  pro¬ 
prietary  products  that  inhibit  program  portability.  They  state  that  4GLs  may  be  suitable  for 
small  system  requirements,  but  that  they  are  generally  unsuitable  for  complex  programs  re¬ 
quiring  intricate  data  handling  and  that  3GLs  are  often  a  much  better  solution.  Although 
these  arguments  may  be  valid  in  some  instances,  some  very  capable  4GLs  have  already 
proven  their  worth  in  very  demanding  and  complex  environments.  Ultimately,  the  suitabil¬ 
ity  of  4GLs  very  much  depends  on  the  particular  system  architecture  and  ^plication  re¬ 
quirements.  The  areas  where  4GLs  are  generally  recognized  to  provide  increased 
productivity  over  3GLs,  however,  are  shown  in  the  Figure  8. 
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c.  Computer-Aided  Software  Engineering  (CASE)  Tools 

Another  architectural  tool  that  has  been  designed  to  automate  large  portions 
of  the  application  development  process  is  a  set  of  CASE  tools.  CASE  tools  can  play  an  im¬ 
portant  role  in  the  application  development  environment  (ADE)  by  providing  a  central 
repository  for  project  planning,  management  and  support  activities,  documentation,  config¬ 
uration  control,  and  a  software  re-use  while  facilitating  better  communications  among 
project  members.  Such  features  can  be  of  great  value  in  a  complex  distributed  environment, 
potentially  dramatically  increasing  productivity  and  reducing  costs. 

In  the  past,  however,  CASE  tools  have  met  widi  mixed  reviews  and  have  not 
always  lived  up  to  expectations.  Criticisms  have  generally  been  related  to  the  high  expense 
associated  with  the  purchase  of  CASE  tools  and  the  lack  of  technological  maturity.  Accord¬ 
ing  to  one  authority,  ‘To  be  effective,  CASE  tools  must  work  closely  with  other  develop¬ 
ment  tools  such  as  repositories,  code  generators,  and  front-end  development  tools. 
Unfortunately,  few  CASE  tools  have  been  able  to  do  this  well  enough  yet”  [Ref.  6:p.  223]. 
Ideally,  developers  need  1-CASE  (Integrated  CASE)  tools  that  combine  upper-CASE  tools 
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and  lowcr-CASE  tools  so  that  they  can  be  used  together  to  develop  network  applications. 
Upper-CASE  tools  are  responsible  for  the  mapping  of  business  processes  and  data  flow  de¬ 
signs,  whereas  lower-CASE  tools  use  those  designs  to  help  generate  code.  Though  ac¬ 
knowledging  weaknesses  in  past  CASE  technology,  the  Gartner  Group  expects  a  “rebirth” 
in  CASE  with  a  new  generation  of  tools  and  predicts  “[a]s  CASE  vendors  take  on  the 
emerging  new  technologies,  CASE-driven  client/server  application  development  will  pick 
up”  [Ref.  23:p.  3]. 

C.  MIGRATION  STRATEGIES 

Defining  a  corporate  IS  objective — such  as  off-loading  the  mainframe  applications 
into  an  open,  client/server  environment — may  be  much  more  easily  said  than  done.  Admit¬ 
tedly,  client/server  and  other  distributed  architectures  that  offer  potentially  large  cost  sav¬ 
ings  may  be  a  desirable  and  achievable  objective,  especially  given  the  advancement  in 
architectural  tools.  Yet,  how  is  this  downsizing  actually  accomplished?  What  kind  of  appli¬ 
cations  are  best  suited  for  an  initial  downsizing?  Moreover,  assuming  identification  of  the 
best  application  to  downsize,  what  is  the  best  method  for  migrating  that  code?  This  section 
will  take  a  look  at  the  issues  behind  the  ultimate  objective,  examining  options  and  opinions 
when  selecting  the  best  application  to  downsize  and  the  available  migration  strategies. 

1.  Selecting  the  Best  Application(s)  to  Downsize 

Most  IS  experts  agree  that  most  successful  downsizing  projects  occur  by  migrat¬ 
ing  only  one  application  at  a  time  (or  portions  thereof)  and  only  after  selection  of  suitable 
“candidates.”  One  general  statement  often  made  is  that  typical  legacy  systems  with  high 
maintenan  e  costs  and  low  mission-criticality  are  the  ideal  ones  to  immediately  downsize 
and  should  be  used  as  pilot  projects.  The  Integrated  Automation  (LA)  Coiporation  makes 
such  an  argument  and  provides  general  guidelines  for  downsizing  applications  in  Figure  9. 
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Certainly,  strong  consideration  is  due  to  issues  of  mission-criticality  and  mainte¬ 
nance  loads.  Governing  decision  making  processes  by  those  criteria  alone,  however,  would 
be  to  make  decisions  according  to  relatively  superficial  heuristics,  as  deplete^  in  Figure  9. 
Another  dimension  that  is  critical  to  examine  when  analyzing  the  feasibility  of  downsizing 
an  application  is  the  actual  structure  of  the  code.  It  is  important  to  have  code  that  has  clearly 
defined  functions  and  interfaces.  Codes  with  such  characteristics  will  make  any  re-engi¬ 
neering  and  re-writing  of  complex  code  much  less  costly  in  terms  of  time  and  money.  The 
structure  of  the  code  may  also  help  determine  performance  parameters  in  the  new  environ¬ 
ment  and  the  difficulty  of  separating  portions  of  applications  to  enhance  end-user  features. 
Figure  9  depicts  the  structure  of  the  application  code  as  a  third  dimension  to  consider  when 
choosing  downsizing  candidates.  Common  features  of  code  that  may  lend  an  application  as 
an  appropriate  candidate  for  downsizing  may  include: 

•  Interactive  processes  between  end-user  and  application 

•  Isolated  functional  components  where  application  logic  can  be  easily  separated 
from  data  and  user  I/O  processes. 
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•  Well-defined  function  interfaces  (i.e.,  one  entry  and  one  exit). 

•  Data  structures  that  are  easily  separable  from  application  logic  (i.e.,  SQL  calls  are 
separated  into  a  logical  set  of  functions). 

•  New  applications — so  they  can  be  optimized  for  the  client/server  environment. 
[Ref.  24:p.  3-2] 

On  the  other  end  of  the  spectrum,  applications  that  should  not  be  downsized  are 
those  where  the  application  and  code  have  characteristics  exactly  opposite  to  the  ideal  can¬ 
didates.  These  may  include  applications  where  there  are  few  interactive  processes,  have 
poorly  defined  function  interfaces,  and  where  data  structures  are  integrated  into  the  appli¬ 
cation  logic.  More  intuitively,  applications  that  are  seldomly  used,  frequently  changed,  or 
about  to  be  replaced  are  also  not  appealing  candidates  for  downsizing  [Ref.  24:p.  3-4]. 


2.  Migration  Techniques 

Selecting  appropriate  applications  to  downsize  is  only  the  first  step  in 
implementing  a  migration  strategy.  Having  determined  “what”  to  downsize,  the  next  ques¬ 
tion  becomes  “how?”  When  deciding  on  the  particular  method,  Gartner  Group  recom¬ 
mends  first  adopting  a  “global”  strategy  with  regard  to  the  ultimate  fate  of  the  mainframe. 
If  the  goal  is  to  junk  the  mainframe  in  the  near  future,  for  example,  it  can  affect  the  migra¬ 
tion  technique.  Gartner  Group  believes  that  organizations  need  to  commit  to  either  (1) 
growing  with  their  traditional  mainframes,  (2)  fading  out  the  mainframe  while  preparing 
replacement  systems,  or  (3)  killing  the  mainframe  as  quickly  as  possible.  [Ref.  7:p.  32] 

With  an  overall  strategy  governing  the  fate  of  the  mainfiame,  the  technique  for 
migrating  an  application  becomes  more  obvious.  Such  options  generally  include: 

•  Maintain  the  status  quo.  When  the  application  meets  the  criteria  for  candidates  that 
are  not  good  choices  for  downsizing,  leaving  the  application  on  the  mainframe 
may  be  die  best  option.  As  modifications  and  patches  are  required  to  meet  chang¬ 
ing  business  needs,  maintenance  continues  to  be  performed  in  the  traditional  fash¬ 
ion. 

•  Surround  and  integrate.  With  this  methodology,  the  application  remains  mostly 
intact  on  the  host  The  idea  is  to  build  around  mainframe  and  integrate  it  within 
client/server  architecture.  Accessory  applications  may  be  added  to  increase  the 
overall  level  of  functionality.  One  typical  strategy  is  to  simply  add  a  GUI  interface 
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to  the  client  while  leaving  the  bulk  of  the  application  processing  and  data  on  the 
mainframe. 

•  Tranter.  This  requires  moving  the  application  to  the  new  platform  as  inexpensive¬ 
ly  as  possible.  The  assumption  here  is  that  the  code  is  relatively  portable. 

•  Convert  or  emulate.  Because  the  code  may  not  be  portable,  conversion  tools  can 
be  used  to  modify  the  code  to  allow  it  to  run  on  the  downsized  platform.  Another 
possibility  is  to  emulate  the  application  with  a  product  that  emulates  cunent  envi¬ 
ronment  This  is  a  low-cost  alternative  that  retains  familiar  features  and  function¬ 
ality. 

•  Reengineer.  In  this  instance,  the  old  code  is  still  useful  and  applicable  enough  to 
the  downsized  environment  and  business  processes — ^the  code  simply  needs  to  be 
reengineered.  Reengineering  code  (not  to  be  confused  with  reengineering  business 
processes)  is  a  software  methodology  that  capitalizes  on  much  of  the  logic  of  the 
old  code  to  help  develop  more  structured,  streamlined,  and  efficient  new  code.  Of¬ 
ten  the  new  application  is  written  using  the  old  ^plication  as  a  skeleton  and  up¬ 
grades  are  added  as  appropriate.  CASE  tools  and  4GLs  are  useful  tools.  This 
process  may  be  both  time  consuming  and  expensive.  There  is  the  added  danger  of 
replicating  inefficient  and  outdated  code,  not  to  mention  outdated  business 
functions. 

•  Replace.  Business  processes  may  have  been  reengineered  (in  this  instance,  reengi¬ 
neering  refers  to  streamlining  of  business  processes,  not  code — ^more  about  busi¬ 
ness  reengineering  is  discussed  in  the  next  chapter)  making  the  old  programs 
obsolete  or  reengineering  the  code  may  be  prohibitively  expensive  in  light  of  other 
options.  The  old  code  is  simply  discarded  in  favor  of  more  appealing  software  al¬ 
ternatives.  New  tools  enable  faster,  more  efficient  development  of  applications. 
Off-the-shelf  software  also  looks  attractive. 
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IV.  ASSESSING  THE  RISK 


Some  view  the  trend  that  has  resulted  in  the  downsizing  of  information  systems  as  a 
dangerous  fad.  Every  CIO  must  have  an  instinctive  fear  of  their  CEO  glancing  at  an  IS  jour¬ 
nal,  reading  an  eye-catching  article  about  a  downsizing  success  story,  and  receiving  a  fol¬ 
low-up  phone  call  with  the  major  question  of  “Why  aren’t  we  downsizing?’’ 

The  crucial  question  of  “to  downsize  or  not  to  downsize”  has  no  easy  answer.  Many 
questions  on  a  wide  range  of  topics  need  to  be  studied  and  analyzed  carefully.  Downsizing 
a  major  information  system  can  be  a  risky  proposition  with  significant  consequences  for  an 
organization.  Being  able  to  accurately  assess  the  risks  associated  with  downsizing  and  to 
make  objective  and  intelligent  decisions  to  the  downsizing  question  is  a  critical  skill. 

For  many  organizations,  business  imperatives  may  pressure  downsizing  initiatives. 
Perhaps  a  move  to  a  new  buil<ting  with  new  space  limitations,  cost-saving  mandates  from 
above,  or  new  software  requirements  prompt  the  initial  move— and  limit  possible  options. 
In  such  cases,  downsizing  may  not  be  so  much  an  option  as  a  directive.  In  other  instances, 
an  organizations  may  view  downsizing  as  an  opportunity  to  stay  ahead  of  technology  and 
gain  a  competitive  advantage.  This  organization  may  have  fewer  constraints  on  their  op¬ 
tions.  Whether  an  organization  is  downsizing  an  information  system  in  re^nse  to  a  direc¬ 
tive  or  an  opportunity,  it  is  important  to  properly  consider  the  risks  and  perform  iqipropriate 
studies  associated  with  that  decision.  These  studies  have  been  typically  labelled /ea»*bi7i0' 
studies  by  systems  analysts  and  form  the  centerpiece  of  the  systems  analysis  and  the  sys¬ 
tems  development  life  cycle  (SDLC). 

This  chapter  will  examine  three  feasibility  studies  that  are  helpful  in  analyzing  the 
risks  associated  with  downsizing  information  systems  and  should  be  completed  during 
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various  stages  of  the  SDLC  and  prior  to  committing  additional  resources.  These  feasibility 
studies  (or  analyses)  typically  include  operational,  technical,  and  economic  factors.  To 
broaden  the  scope  of  the  operational  analysis  to  include  more  organizational  implications, 
the  operational  feasibility  study  is  re-labelled  as  an  organizational  analysis.  Additionally, 
as  is  often  done,  the  economic  analysis  portion  of  this  chapter  is  discussed  in  terms  of  a 
cost/benefit  analysis.  Because  these  feasibility  studies  are  completed  as  an  integral  part  of 
the  systems  analysis  portion  of  the  SDLC,  it  is  important  to  first  provide  a  brief  overview 
of  the  systems  analysis  process  prior  to  addressing  the  feasibility  studies. 

A.  OVERVIEW  OF  SYSTEMS  ANALYSIS 

Systems  analysis  is  the  “study  of  a  current  business  system  and  its  problems,  the  def¬ 
inition  of  business  needs  and  requirements,  and  the  evaluation  of  alternative  solutions” 
[Ref.  25:p.  9].  Assessing  the  risk  of  downsizing  is  an  essential  part  of  the  systems  analysis 
portion  of  the  systems  development  life  cycle  (SDLC).  The  correct  decision  to  downsize  an 
information  system  depends  on  an  understanding  of  the  business  system  and  its  problems, 
the  end-user  requirements,  and  an  understanding  of  the  architectural  choices.  Systems  anal¬ 
ysis  is  a  crucial  phase  of  the  SDLC.  Though  many  different  models  exist  for  the  SDLC,  all 
models  generally  incorporate  a  phased  approach  wherein  the  systems  analysis  portion  plays 
a  key  role  in  initially  surveying  the  project  scope  and  feasibility  and  ultimately  selecting 
the  best  solution  firom  candidate  alternatives.  Figure  10  depicts  the  phases  of  systems  anal¬ 
ysis  in  one  model  of  the  SDLC. 

1.  The  Systems  Analysis  Process 

Systems  analysis  is  a  “process  performed  by  many  but  practiced  by  few” 
[Ref.  25  :p.  134].  Though  it  is  the  crucial  process  upon  which  all  the  subsequent  phases  of 
the  SDLC  depend,  it  is  one  that  is  also  too  often  guided  by  ill-defined  standards  and  a 
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Figure  10:  The  Systems  Development  Life  Cycle  (SDLC) 

[Ref.  25:p.  140] _ 


haphazard  approach.  Good  systc  design  and  implementation  are  dependent  on  proper 
systems  analysis.  The  SDLC  diagram  suggests  a  more  structured  methodology  to  ap¬ 
proaching  systems  analysis,  an  approach  that  will  enable  a  more  structured  analysis  and  an 
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opportunity  to  evaluate  risks.  The  four  phases  illustrated  in  the  system  analysis  portion  of 
die  diagram  are: 

•  Survey.  A  survey  of  the  project  scope  and  feasibility  that  serves  as  a  preliminary 
investigation  of  the  propos^  project  Initial  parameters  of  the  project  are  esub- 
lished  to  include  project  scope,  perceived  problems,  constraints,  possible  solu¬ 
tions,  and  intended  goals. 

•  Study.  An  establishment  of  a  baseline  of  the  current  business  needs  and  system  to 
provide  insight  to  current  problems,  business  needs,  and  implications  of  possible 
solutions. 

•  Definition.  A  determination  of  the  end-users’  requirements.  The  emphasis  is  on 
what  the  system  is  supposed  to  do,  not  how. 

•  Selection.  The  process  of  choosing  the  most  feasible  solution  from  the  available 
alternatives  with  a  closer  look  at  operational,  technical,  and  economic  feasibility. 
[Ref.  25:p.  167-169] 

2.  Determining  Feasibility 

One  purpose  of  systems  analysis  is  to  estimate  the  risk  associated  with  a  project 
Feasibility  studies  should  be  conducted  throughout  all  phases  of  the  systems  analysis  por¬ 
tion  of  the  SDLC  and  serve  as  checkpoints  for  management  reevaluation  of  the  project 
This  logical  and  objective  methodology  supports  an  ^roach  that  has  been  dubbed  a 
“creeping  commitment”  approach — as  the  project’s  feasibility  is  progressively  validated 
after  each  stage,  the  organization’s  commitment  in  terms  of  resources  progressively  in¬ 
creases.  If  a  feasibility  study  determines  that  risk  is  determined  to  be  unacceptable,  despite 
any  preceding  commitments,  then  management  should  not  continue  with  it 
[Ref.  25:p.  767] 

In  the  early  stages  of  systems  analysis,  such  as  the  survey  and  study  phase,  the 
feasibility  study  cannot  be  completed  witii  great  detail  as  no  technically  specific  solutions 
have  been  investigated.  In  the  last  phase  of  systems  analysis,  the  selection  phase,  technical 
alternatives  have  been  specified  and  the  feasibility  study  becomes  much  more  accurate.  It 
is  important  for  feasibility  studies  to  be  conducted — to  some  degree — ^after  each  phase  as 
conclusions  can  change  with  a  better  understanding  of  current  problems,  business  and  end- 
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user  requirements,  and  alternative  solutions.  Projects  that  may  iq>pear  to  be  extremely 
appealing  at  first  may  later  turn  out  to  be  unattractive  in  light  of  increased  information.  It 
is  through  the  process  of  constantly  challenging  the  organizational,  technical,  and  econom¬ 
ic  implications  of  the  proposed  project  that  IS  risks  are  objectively  assessed  and  minimized. 

B.  ORGANIZATIONAL  ANALYSIS 

It  is  no  longer  enough  for  the  IS  department  to  merely  support  and  respond'to  ad  hoc 
departmental  needs.  The  role  of  IT  and  the  corresponding  IS  architecture  has  become  crit¬ 
ically  linked  with  the  strategy  and  success  of  an  organization.  CEOs  and  CIOs  need  to  take 
a  look  at  many  organizational  factors  prior  to  making  any  commitments  on  whether  to 
downsize  and  prior  to  deciding  what  to  downsize  to.  Downsizing  is  a  process  that  reshapes 
the  way  organizations  work  and  compete;  top-level  managers  must  ensure  that  the  process 
will  work  and  that  the  reshaped  organization  is  in  the  intended  form.  In  order  to  do  this, 
several  prerequisites  must  be  fulfilled.  Unless  these  prerequisites  axe  met,  the  organization 
faces  potentiaUy  high  risks  of  failure.  These  failures  may  be  manifested  by  either  a  failure 
to  meet  cost  and  performance  goals,  or  a  tnuisition  to  a  downsized  environment  that  fails 
to  meet  organizational  requirements.  In  order  to  avoid  these  risks,  the  top  managers  Uke  the 
CEO  and  CIO  must 

•  Understand  the  business  needs 

•  Understand  the  business  processes 

•  Generate  organizational  support 

This  section  will  examine  these  top-level  manager  responsibilities  to  the  organiza- 
tion—all  essential  requirements  that  must  be  met  prior  to  committing  to  the  downsizing  of 
major  information  systems. 
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1.  Understanding  the  Business  Needs 

The  previous  chapter  described  IT  as  a  strategic  asset  IT,  however,  can  only  be  a 
strategic  asset  to  the  degree  that  it  supports  the  business  strategy.  IS  systems  must  work  in 
concert  with  business  strategy — one  must  be  a  reflection  of  the  other  (it  should  be  foomot- 
ed,  here,  that  a  “business”  strategy  is  not  limited  to  private-sector  Arms;  DoD  units,  such 
as  ONI  also  need  to  develop  a  similar  strategy  on  how  best  to  carry  out  their  assigned  mis¬ 
sions).  Thus,  as  business  strategy  is  planned  and  outlined,  so  too  must  IS  strategy  be 
planned  and  outlined.  In  this  process,  specific  methodologies  may  be  used  to  analyze  or  en¬ 
sure  that  IS  aligns  itself  to  the  business  strategy.  For  downsizing  to  work,  planning  efforts 
must  ensure  that  the  downsized  product  is  relevant  to  the  corporate  strategy.  Accordingly, 
DoD  and  private  corporations  need  to  examine  and  understand  the  key  ingredients  that 
make  their  organization  function  successfully. 

Analysis  of  critical  success  factors  in  strategic  IS  planning  may  serve  as  a  useful 
first  step.  According  to  one  IS  strategist,  “critical  success  factors  are  the  limited  number  of 
areas  in  which  satisfactory  results  will  ensure  competitive  performance  for  the  individual 
department  or  organization.  Critical  success  factors  are  the  few  key  areas  where  ‘things 
must  go  right’  for  the  business  to  flourish  and  the  manager’s  goals  to  be  attained”  [Ref.  26]. 
Critical  success  factors  can  help  a  corporation  analyze  information  systems  they  need  to  de¬ 
velop,  maintain,  or  change. 

The  management  of  Federal  Express,  the  leading  overnight  package  carrier  in  the 
world,  lists  five  critical  success  factors  upon  which  the  company’s  phenomenal  success  de¬ 
pends.  The  first  of  these,  “(to)  continuously  improve  quality,”  is  integrally  linked  to  IT. 
Federal  express  handles  1.5  million  packages  a  day,  using  430  aircraft,  31,000  delivery 
vans,  and  91,000  employees  at  1,7(X)  locations  worldwide.  Federal  Express’  COSMOS  IIB 
IS  system,  which  consists  of  nine  IBM  3090s  linked  to  75  dispatch  centers  and  24  call  cen¬ 
ters,  handles  the  resulting  14  million  transactions  a  day  or  10  transactions  per  package  in 
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the  system.  Not  only  is  COSMOS  DDB  the  major  on-line  system  for  handling  routing  infor¬ 
mation  and  tracking  package  status,  but  it  is  also  the  key  component  in  providing  feedback 
for  employees  on  quality  factors  such  as  on-dme  delivery,  correct  billing,  calls  answered 
on  time,  resolution  of  customer  complaints,  and  employee  satisfaction.  For  Federal  Ex¬ 
press,  management  understands  that  quality  is  an  essential  factor  for  success — and  that 
their  IS  system  is  largely  responsible  for  implementing  that  strategy.  [Ref.  l  :p.  72-78] 

Another  popular  methodology  (among  a  vast  array  of  others)  for  analysis  of  busi¬ 
ness  needs  is  the  scenario  approach.  As  the  name  implies,  the  scenario  approach  uses  “what 
if’  hypothetical  situations  to  analyze  and  plan  for  future  business  needs.  In  these  scenarios, 
top  managers  employ  key  variables  such  as  the  environment,  trends,  and  events  to  analyze 
and  weigh  what  could  happen  under  different  sets  of  circumstances.  Computer  based  deci¬ 
sion  support  systems  (DSS)  can  be  used  to  help  quantify  the  results  and  provide  objective 
results  with  which  to  help  develop  and  implement  the  most  appropriate  IS  architecture. 
[Ref.  l:p.  1 14]  No  single  method  is  highlighted  as  a  more  appropriate  than  another,  what 
all  have  in  common,  though,  are  systematic  and  objective  approaches  to  understanding  the 
business  needs  for  the  purpose  of  plaruiing  and  applying  the  most  advantageous  IS 
architecture. 

2.  Understanding  the  Business  Processes 

Understanding  of  the  business  processes  goes  one  step  beyond  identification  of 
the  business  needs.  A  business  need  may  be  fulfilled  without  an  understanding  of  the  busi¬ 
ness  processes.  What  can  result  is  a  system  that  works,  but  not  as  well  as  it  could  work. 
With  an  imderstanding  of  the  business  processes,  all  aspects  of  a  system  are  broken  down 
to  their  individual  components  to  the  point  where  aU  linkages,  interdependencies,  and  rela¬ 
tionships  among  parts  are  clearly  understood.  With  this  accomplished,  an  organization  can 
identify  and  correct  inefficiencies  in  a  system.  Information  “barriers,  bottlenecks,  and 
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blackholes”  can  be  isolated  prior  to  automation  of  the  process  by  implementation  of  a  new 
system.  By  taking  this  step  back  from  the  playing  field,  IS  professionals  avoid  the  mistake 
of  applying  the  right  technology  to  the  wrong  problem.  By  removing  those  inefficiencies 
in  the  system,  the  only  processes  that  theoretically  remain  are  those  that  add  value.  Stream¬ 
lining  of  these  remaining  processes  ensures  maximum  efficiency  and  productivity. 
Through  this  rethinking  of  the  business  processes,  IS  professionals  identify  the  core  value¬ 
adding  processes.  When  this  process  is  automated,  productivity  can  increase  dramatically 
instead  of  by  token  incremental  improvement 

a.  Business  Reengineering 

In  their  book  Reengineering  the  Corporation,  authors  Michael  Hammer  and 
James  Champy  champion  the  idea  of  reinventing  American  con^anies  through  the  process 
of  business  reengineering — ^“the  fundamental  rethinking  and  radical  redesign  of  business 
processes  to  achieve  dramatic  improvements  in  critical,  contemporary  measures  of  perfor¬ 
mance,  such  as  cost,  quality,  service,  and  speed”  [Ref.  27:p.  32].  The  four  key  words  that 
the  authors  extract  from  this  definition  to  explain  this  concept  are  fundamental,  radical,  dra¬ 
matic,  and  processes. 

The  first  key  word,  “fundamental,”  refers  to  the  notion  that  companies  must 
ask  themselves  basic  and  fundamental  questions  about  their  operations:  “Why  do  we  do 
what  we  do?  And  why  do  we  do  it  the  way  we  do?”  [Ref.  27 :p.  32].  Often,  this  questioning 
helps  identify  commonly  held,  yet  obsolete  and  faulty,  assumptions  about  how  business  is 
conducted. 

“Radical”  refers  to  the  need  for  businesses  to  avoid  timidly  superficial  chang¬ 
es  in  the  business  processes;  “reengineering  is  about  business  reinvention — not  business 
improvement,  business  enhancement,  or  business  modification”  [Ref.  27  ;p.  33]. 
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When  using  the  word  “dramatic”  in  the  definition.  Hammer  and  Champy  ad¬ 
vocate  major,  non-incremental  changes  to  the  processes.  More  traditional  approaches  have 
called  for  the  fine-tuning  of  existing  methods.  When  called  for.  Hammer  and  Chancy 
argue  for  a  different  approach: 


Reengineering  isn’t  about  making  marginal  or  incremental  improvements  butabout 
achieving  quantum  leaps  in  performance.  If  a  company  falls  10  percent  short  of 
where  it  should  be,  if  its  costs  come  in  10  percent  too  high,  if  its  quality  is  10  percent 
too  low,  if  its  customer  service  performance  needs  a  10  percent  boost,  that  company 
does  not  need  reengineering.  More  conventional  methods,  from  exhorting  the  troops 
to  establishing  incremental  quality  programs,  can  dig  a  company  out  of  a  10  percent 
hole.  Reengineering  should  be  brought  in  only  when  a  need  exists  for  heavy  blasting. 
Marginal  improvement  requires  fine-tuning;  dramatic  improvement  demands 
blowing  up  the  old  and  replacing  it  with  something  new.  [Ref.  27 :p.  33-34] 

The  last  key  word  in  the  definition,  “process,”  is  the  most  important  element 
in  business  reengineering,  yet  the  most  difficult  conceptually  for  managers.  Corporate  man¬ 
agers  have  been  bred  to  instinctively  relate  to  their  jobs  in  terms  of  people,  their  job  descrip¬ 
tions,  tasks,  and  organizational  structures.  A  process  is  different  in  that  it  focuses  not  on 
these  existing  constraints,  but  on  the  collection  of  activities  that  acts  on  one  or  more  inputs 
to  create  a  value-added  output  Hammer  and  Champy  call  for  the  fundamental  rethinking 
and  radical  redesign  of  this  collection  of  activities,  not  the  familiar  organizational  entities. 
In  traditional  attempts  to  cope  with  crises,  corporations  have  typically  selected  from  a  menu 
of  three  choices  to  resolve  their  dilemma;  (1)  bring  in  new  people,  (2)  automate  the  task 
with  bigger  and  faster  machines,  or  (3)  restructure  the  organizational  chart.  These  options 
usually  result  in  only  superfreial  and  marginal  improvements.  By  reengineering  the  pro¬ 
cesses,  a  new  option  is  added  to  the  menu,  with  potentially  dramatic  and  radical 
improvement  [Ref.  27] 

As  suggested  in  the  previous  chapter,  IT  can  play  a  key  role  in  business  re¬ 
engineering  as  an  enabling  force.  According  to  Hammer  and  Champy,  however,  IT’s  key 
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role  is  all  too  often  miscast  and  results  in  exacerbating  the  existing  situation.  Automation 
of  existing  processes.  Hammer  and  Champy  insist,  is  not  reengineering. 

...to  paraphrase  what  is  often  said  about  money  and  government,  merely  throwing 
computers  at  an  existing  business  problem  does  not  cause  it  to  be  reengineered.  In 
fact,  the  misuse  of  technology  can  block  reengineering  altogether  by  reirtforcing  old 
ways  of  thinking  and  old  behavior  patterns.  [Ref.  27] 

Using  IT  to  challenge  old  assumptions,  alter  outmoded  and  inefficient  operat¬ 
ing  methods,  and  to  break  traditional  rules  is  what  reengineering  is  all  about  Utilization  of 
Electronic  Data  Interchange  to  break  traditional  organizational  boundaries,  exploitation  of 
database  technology  to  share  information  simultaneously,  and  harnessing  the  power  of  mi¬ 
croprocessor  to  bring  mainframe  computing  powo-  to  the  desktop  are  all  examples  of  free¬ 
ing  an  organization  from  constraining  assiunptions.  What  IT  enables  is  the  "notion  of 
discontinuous  thinking — ^“identifying  and  abandoning  the  outdated  rules  and  fundamental 
assumptions  that  underlie  current  business  operations”  [Ref.  27qp.3]. 

b.  The  Total  Quality  Movement 

Hammer’s  and  Champy ’s  program  of  business  reengineering  shares  some 
conunon  ground  with  some  familiar  business  improvement  programs,  but  differs  radically 
from  others.  The  Total  Quality  Management  (TQM)  program  and  the  U.S.  Navy’s  Total 
(Quality  Leadership  (TQL)  initiatives,  for  example,  share  a  similar  theme  with  business  re¬ 
engineering  in  that  both  recognize  the  importance  of  studying  the  business  processes  and 
the  primacy  of  the  customer.  Where  TQM  and  TQL  differ,  though,  is  that  these  programs 
seek  to  gain  improvement  of  business  process  through  continuous,  incremental  improve¬ 
ment  rather  that  business  reengineering’s  radical  and  dramatic  remedy. 

(Quality  programs  work  within  the  framework  of  a  company’s  existing  processes  and 
seek  to  enhance  them  by  means  of  what  the  Japanese  call  kaizen,  or  continuous  in- 
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CFcmental  improvement  The  aim  is  to  do  what  we  already  do,  only  to  do  it  better. 

[Ref.  27:  p.49]. 

Manifestations  of  the  total  quality  movement  are  seen  in  various  management 
and  organizational  development  techniques  designed  to  improve  employee  productivity. 
Dramatic  success  stories  in  management  such  as  the  Japanese  utilization  of  W-  Edward 
Deming’s  TQM  program  to  help  revitalize  the  Japanese  economy,  have  fostered  a  greater 
appreciation  for  iimovative  management  principles  in  the  American  economy.  These  new 
principles  stress  quality,  process  redesign,  employee  involvement  self-managing  work¬ 
groups,  teamwork,  and  job  redesign.  Whether  the  methods  for  approaching  the  analysis  of 
an  organization  have  been  business  reengineering,  TQM,  or  the  sociotechnical  system 
(STS)  approach,  the  pervasive  trend  has  been  a  closer  examination  of  the  more  elusive, 
non-tradidonal  aspects  of  organizations  with  an  emphasis  on  the  business  processes.  Peter 
Senge,  director  of  the  Systems  Thinking  and  Organizational  Learning  Program  at  MIT’s 
Sloan  School  of  Management  encourages  such  thinking  in  his  recent  book.  The  Fifth  Dis¬ 
cipline:  The  Art  and  Practice  of  the  Learning  Organization,  in  which  he  prompts  organiza¬ 
tions  to  become  learning  organizations  in  order  to  survive  [Ref.  28]. 

As  evidenced  through  numerous  corporate  case  studies,  IT  can  act  as  a  cata¬ 
lyst  for  Hammer’s  and  Champy’s  version  of  business  reengineering  and  other  programs  of 
process  improvement  IT  has  characteristically  been  the  tool  through  which  traditional  as¬ 
sumptions  have  been  broken  and  new  ways  of  operating  have  become  possible.  The  oppor¬ 
tunities  afforded  by  the  new  technologies  available  in  a  downsized  environment  can 
translate  into  new  processes  for  doing  business,  new  windows  of  opportunity.  Nonetheless, 
when  assessing  the  risks  inherent  in  downsizing,  it  is  inherently  important  to  understand  the 
processes  of  the  business.  That  is  what  this  section  has  tried  to  emphasize.  Whether  or  not 
a  business  ultimately  undertakes  a  downsizing  proposition,  a  critical  understanding  of  the 


60 


processes  can  ensure  a  better  evaluation  of  the  possibly  revolutionizing  benefits  of  down¬ 
sizing  or  the  overly  daunting  pitfalls. 

3.  Generating  Organizational  Support 

The  greatest  risks  with  downsizing  may  not  be  associated  with  the  proper  analysis 
of  business  process,  a  thorough  performance  analysis,  or  an  accurate  cost-benefit  justifica¬ 
tion.  Instead,  the  downsizing  issues  that  may  pose  the  greatest  obstacles  to  progress  are  re¬ 
lated  to  human  factors.  Downsizing  can  have  generate  organizational  changes  that  can  have 
a  profound  impact  on  an  organization’s  operating  procedures  and  corporate  culture.  The  re¬ 
sulting  fear  factor  can  create  widespread  and  unpredictable  consequences  that  can  affect  the 
success  of  the  downsizing  process.  Before  proceeding  too  quickly  with  any  downsizing 
plans,  it  is  an  absolute  necessity  to  ensure  that  top  corporate  officials  have  “bought  off’  on 
the  idea.  Unless  sustained  top  management  commitment  is  forthcoming  to  help  initiate  the 
process  and  overcome  a  resistance  to  change,  the  success  of  downsizing  is  at  risk. 

a.  Top  Management  Support 

Downsizing  is  as  much  a  political  issue  as  a  technical  issue.  Top  management 
commitment  is  crucial  in  light  of  a  potentially  difficult  migration  process  full  of  volatile 
cultural  and  social  upheaval.  External  factors  such  as  underestimation  of  development  or 
training  costs  can  shortchange  the  process.  Internal  conflict  due  to  potential  job  losses  can 
delay  and  even  sabotage  progress.  In  face  of  unanticipated  pitfalls,  lack  of  absolute  convic¬ 
tion  and  support  to  guide  the  downsizing  initiative  will  exacerbate  a  deteriorating  situation. 
Lack  of  executive  support  to  provide  constant  leadership  and  guidance  within  a  strategic 
framework  will  ensure  failure. 

Despite  the  criticality  of  obtaining  top  management  support  in  downsizing  in¬ 
formation  systems,  the  task  may  be  more  challenging  than  one  might  expect.  A  study  done 
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by  the  Massachusetts  Institute  of  Technology’s  (MIT)  Sloan  School  revealed  surprising  at¬ 
titudes  towards  information  systems  on  the  part  of  CEOs.  [Ref.  1  :p.  54-56]  The  study  in¬ 
volved  two-hour  interviews  with  CEOs  from  84  organizations  within  ten  different 
industries  and  focussed  around  the  CEOs’  perceived  value  and  expectations  from  IT  invest¬ 
ments.  The  results  were  disappointing  for  IS  departments.  Fifty-two  percent  of  the  CEOs 
said  that  they  were  too  unknowledgable  about  IT  to  direct  their  investments.  The  other  48 
percent  (see  Figure  1 1)  of  the  CEOs  had  varying  attitudes  about  IT  that  reflected  various 
degrees  of  confidence  in  informations  systems  themselves  and  the  IS  departments.  What 
the  study  reveals  is  greater  CEO  confidence  in  the  value  of  IS  technology  (38  percent)  than 
confidence  in  the  personnel  (20  percent).  Furthermore,  only  12  percent  of  the  CEOs  had 
high  confidence  in  both  the  technology  and  the  people.  Fi?  re  1 1  illustrates  why  obtaining 
top  management  support  may  be  more  difficult  than  anticipated. 


Quadrant  1 

Quadrant  2 

(12  percent) 

(26  percent) 

Quadrants 

Quadrant  1 

(8  percent) 

(2  percent) 

I  figufenrciU  Perceptions  of  la  Systems  andTersonnei  [Ketri:  p. 


In  order  to  overcome  possible  foot-dragging  by  CEOs,  it  becomes  the  respon¬ 
sibility  of  the  CIO  to  provide  the  leadership  necessary  to  generate  top-management  confi¬ 
dence  in  IS  technology  and  personnel.  If  it  does  not  already  exist,  establishing  confidence 
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in  IS  will  not  be  an  overnight  process.  Because  of  the  career-threatening  high  stakes  in¬ 
volved  in  rr,  the  acronym  CIO  has  sometimes  facetiously  been  said  to  stand  for  “Career  Is 
Over.”  Instead  of  fostering  that  negativism,  Michael  Hammer  suggests  that  it  should  stand 
for  “Chief  Innovation  Officer,”  with  the  IT  executive  using  the  position  to  take  charge  “as 
a  leader  of  a  team  that  identffies  new  opportunities  and  implements  new  ways  of  doing 
business”  [Ref.  3:p.  1 1].  Accordingly,  the  CIO  must  establish  credibility  by  showing  he  or 
she  understands  business  needs  and  processes  and  demonstrating  how  the  IS  department 
can  help  increase  the  technological  maturity  of  an  organization  through  appropriate  tech¬ 
nologies.  The  CIO’s  ability  to  convincingly  demonstrate  and  sell  a  vision  for  new  technol¬ 
ogies  to  the  CEO  is  the  key  hurdle  for  any  major  IS  project  Getting  the  CIO  and  CEO  to 
function  as  a  team  is  a  major  prerequisite  to  further  progress. 

b.  Managing  Resistance  to  Change 

With  a  united  and  committed  management  the  next  step  is  to  solicit  the  entire 
organization’s  dedication.  Downsizing  information  systems  can  have  a  profound  organiza¬ 
tional  impact  that  can  trigger  many  unanticipated  responses.  If  the  downsizing  project  in¬ 
volves  a  major  move  off  the  mainframe  to  a  PC  LAN,  for  example,  there  will  be  an  inherent 
shift  in  the  need  for  hardware  and  software  skills.  Those  that  may  have  spent  their  entire 
careers  within  the  glass  house  are  likely  to  be  ill-equipped  to  adapt  to  the  requirements  of 
the  new  downsized  environment  Little  incentive  exists  for  a  COBOL  programmer  to  assist 
in  the  downsizing  process  when  the  individual  realizes  he  or  she  is  essentially  helping  to 
make  their  position  obsolete.  In  fact,  much  incentive  exists  for  such  an  individual  to  dis¬ 
courage  a  downsizing  effort  and  perpetuate  the  status  quo. 

Unavoidably,  downsizing  will  require  change — and  inevitably,  change  will 
provoke  resistance.  Reactions  to  change  will  vary  depending  on  the  circumstances,  but  or¬ 
ganizations  commonly  respond  to  change  in  four  negative  ways:  (1)  feelings  of 
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incompetency,  powerlessness,  and  being  unneeded  among  personnel,  (2)  an  atmosphere  of 
confusion  and  unpredictability  throughout  the  organization,  (3)  increased  instances  of  con¬ 
flict,  and  (4)  a  sense  of  loss.  [Ref.  29:p.  397] 


Unless  proactive  steps  are  taken  to  counter  these  negative  reactions,  the  forces 
of  resistance  can  work  to  undermine  any  downsizing  initiatives.  Thus,  the  CEO  and  CIO 
must  acknowledge  these  predictable  responses  and  work  in  concert  to  match  each,  in  turn, 
with  a  countermeasure.  Four  strategies  should  be  considered  to  deal  with  the  changes:  (1) 
establishment  of  training  and  support  for  the  employees,  (2)  realignment  of  formal  roles 
and  relationships  to  coincide  with  change,  (3)  establishment  of  arenas  for  discussion  and 
problem-solving,  and  (4)  development  of  transition  rituals  to  herald  the  “new”  organization 
[Ref.  29:p.  397].  Planning  and  implementation  of  these  countermeasures  to  resistance  can 
help  dissolve  snowballing  forces  of  resistance  from  gaining  momentum  and  thus  minimize 
the  risks  of  downsizing  (see  Figure  12).  Nonetheless,  the  resistance  to  change  and  associ¬ 
ated  emotions  brought  on  by  downsizing  arc  an  unpredictable  risk.  Consideration  and  un¬ 
derstanding  of  the  human  element  are  essential  in  an  effective  risk  analysis  of  downsizing. 


C.  TECHNICAL  ANALYSIS 

The  process  of  properly  assessing  risk  requires  examination  of  different  management 
and  technical  perspectives.  The  previous  section  focused  on  organizational  aspects  of  risk; 
this  one  looks  at  the  technical  aspects.  An  organizationally  sound  project  does  not  neces¬ 
sarily  mean  that  technical  criteria  are  being  fulfilled.  QOs  must  assess  the  feasibility  of  a 
downsizing  project  by  also  asking  and  answering  several  key  technical  questions: 

•  Is  the  proposed  technological  solution  practical?  [Ref.  26:p.  773] 

•  Will  it  meet  all  of  our  current  and  desired  performance  needs? 

1.  Is  the  Technological  Solution  Practical? 

Although  today’s  rapidly  advancing  technology  allows  for  the  possibility  of  many 
technical  solutions,  this  does  not  necessarily  imply  that  the  solution  is  a  practical  one.  Qual¬ 
ifying  as  practical  requires  testing  the  proposed  solution  against  such  issues  as  system  ma¬ 
turity  and  the  track  record  of  technology.  A  practical  system  also  implies  that  it  is  readily 
achievable.  The  complexity  generated  by  the  heterogeneity  in  today’s  computing  environ¬ 
ment  does  not  necessarily  mean  that  a  distributed  system  will  meet  that  requiremenL  Thus, 
the  potential  lack  of  standards  and  interoperability  need  to  be  examined.  Finally,  a  solution 
cannot  be  practical  if  there  is  not  adequate  expertise  or  time  available  to  develop  and  im¬ 
plement  the  proposed  solution. 

a.  System  Maturity 

Many  argue  that  in  contrast  to  the  mainframe’s  legacy  of  stability,  the  PC  and 
workstation  have  just  entered  into  the  big  league  of  corporate  computing  and  are  still  estab¬ 
lishing  and  proving  themselves  as  a  technologically  viable  solution.  A  risk-averse  organi¬ 
zation,  wary  of  vendors  hawking  advantages  of  distributed  computing  in  a  LAN 
environment,  may  look  at  30  years  of  mainframe  experience  in  managing  critical  systems 
in  large  organizations  and  choose  to  bet  on  proven  technology.  Undeniably,  the  mainframe 
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boasts  an  impressive  track  record  of  successes  (as  weU  as  an  embarrassing  number  of  fail¬ 
ures).  Perhaps  this  systems  maturity  and  adaptation  to  its  environment  explains  a  recent 
study  conducted  by  the  Business  Research  Group  of  Newton,  Massachusetts,  that  estimated 
that  75  percent  of  all  computing  tasks  are  still  being  performed  on  the  mainfirame 
[Ref.  30;p.  36]. 

One  explanation  of  the  reluctance  to  downsize  to  smaller  systems  follows: 

Savings  can  be  achieved  by  moving  applications  to  distributed  networks  or  smaller 
host  processors,  but  such  economies  of  scale  alone  are  seldom  motivation  enough  to 
abandon  mainframes...  Many  applications  mn  on  mainframes  because  they  are  of 
such  enormous  financial  value  or  critical  importance  to  the  organization  itself.  As  a 
result,  information  systems  directors  are  reticent  to  mist  such  “mission-critical”  ap¬ 
plications  and  data  outside  of  the  mainframe  environment;  they  simply  feel  uneasy 
about  losing  the  stability  and  reliability  upon  which  they  have  depended  for  so  long. 
[Ref.  30:p.  36] 

Others  agree  that  the  mainframe  is  a  mature  system,  but  footnote  that  it  is  30 
years  too  mature — a  modem  day  dinosaur  by  computing  standards.  This  can^p  believes  that 
the  technology  available  on  the  desktop  is  mature  and  capable  enough  to  meet  their  require¬ 
ments  and  if  they  do  not  invest  in  the  future  now,  there  will  be  no  future  for  them.  The  ar 
gument  is  that  they  cannot  not  afford  to  downsize  unless  they  are  willing  to  lose  any 
competitive  advantage  and  possibly  go  out  of  business.  To  them,  the  debate  is  not  whether 
to  downsize,  but  when  and  what  to  downsize. 


b.  Proprietary  vs.  Open  Systems 

Another  key  issue  that  must  be  technically  analyzed  when  selecting  or  ap¬ 
proving  a  system  is  how  proprietary  or  open  the  target  architecture  is.  The  proprietary  sys¬ 
tem,  a  label  that  has  most  often  been  attached  to  the  mainframe  (although  there  have  been 
significant  recent  strides  toward  more  open  systems),  has  its  obvious  disadvantages  of  sin¬ 
gle  vendor  lock-in  and  high  cost  by  not  allowing  interoperability  with  other  commercial 


66 


components.  Open  systems  try  to  achieve  a  state  where  all  components  are  interoperable. 
Open  systems  are  defined  as: 

An  approach  to  building  information-processing  systems  using  hardware,  software, 
and  networking  components  that  comply  with  industry-accepted  standards  such  as 
OSI  (Open  Systems  Interconnect)  or  POSEX.  [Ref.  6:p.  353] 

What  this  requires  is  a  comprehensive  set  of  standards  that  will  allow 
construction  of  integrated  systems  and  will  provide  interoperability  among  systems  (i.e., 
exchange  of  data)  and  portability  of  applications.  For  the  IS  department,  an  environment  of 
open  computing  systems  would  not  only  generate  the  potential  for  considerable  cost  sav¬ 
ings  (driven  by  intense  competition  and  the  resulting  economies  of  scale),  but  it  would  also 
permit: 

•  IS  departments  to  gain  independence  from  any  specific  IT  vendor. 

•  IS  integration  to  be  achievable  across  heterogeneous  environments. 

•  The  opportunity  to  choose  the  best  of  breed  in  any  technology  area.  [R.ef.  20:p,  1] 

Open  systems  may  be  practical,  but  the  more  important  underlying  question 
is  whether  these  systems  are  achievable.  Reliably  running  and  maintaining  different  system 
elements  running  on  different  sets  of  computers  is  an  inherently  difficult  accomplishment. 
Chief  among  the  risks  of  a  heterogeneous  distributed  environment  are  the  accompanying 
technical  complexity  and  the  lack  of  any  true  standard  to  mitigate  the  effects  of  that  com¬ 
plexity  and  heterogeneity.  Gartner  Group  believes  the  goal  of  complete  interoperability  has 
created  an  “architectural  crisis”  or  sorts: 

IT  moved  from  an  era  of  manageable,  homogeneous  computing  on  monolithic  sys¬ 
tems  in  1980,  to  an  era  of  unmanageable,  heterogeneous,  networked  systems  by 
1990.  In  1980,  after  many  years  of  practice,  IS  understood  how  to  implement  appli¬ 
cations  systems,  buy  from  vendors  and  deal  with  end  users.  By  1990,  virtually  all  as¬ 
pects  of  information  systems  operating  procedures  were  being  overthrown,  primarily 
because  of  the  introduction  of  PCs  and  distributed,  heterogeneous  systems.  Comput¬ 
ing  architectures  have  spun  out  of  control.  Local  Area  Networks  (LANs)  have  expe¬ 
rienced  runaway  growth,  and  desktops  and  servers  of  all  sizes  and  persuasions  have 
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appeared  like  weeds.  Programming  standards  have  eroded  and  the  notion  of  non-re- 
dundant,  consistent,  high-quality  data  is  on  the  compost  heap.  [Ref.  7:p.  1] 

The  range  of  options  created  by  the  technological  flexibility  and  the  response 
to  the  demand  for  open  systems  has  multiplied  the  complexity  of  architectural  choices  and 
the  decision-making  process  and  changed  the  procurement  process.  The  quest  for  an  open 
environment  has  become  a  system  user’s  dream,  but  a  system  integrator’s  nightmare: 

Consider  that  in  an  open  systems  environment  there  are  four  or  five  major  platforms 
to  choose  from,  four  or  more  database  management  system  providers,  five  or  more 
communications  alternatives,  five  or  six  productivity  environments  and  so  on.  It  is 
easy  to  conclude  that  there  can  be  6,000  technical  combinations  possible  for  such  an 
open  environment  (I  have  actually  seen  estimates  of  millions  of  combinations.) 
[Ref.  10:p.  37] 

A  truly  open  system  would  require  universal  compliance  to  one  set  of  stan¬ 
dards:  this  is  where  the  problems  arise  (in  fact  only  proprietary  systems  offer  this  option). 
With  much  invested  in  already  developed  proprietary  standards,  software  developers  rep¬ 
resenting  major  computing  firms  are  trying  to  convince  the  market  to  adopt  their  standard 
to  protect  their  investment  and  secure  an  economically  advantageous  foothold.  The  UNIX 
operating  system,  for  example,  regarded  by  some  as  running  the  most  open  operating  sys¬ 
tem  available,  has  been  fragmented  by  corporate  politics  and  maneuvering.  Being  written 
in  C  enables  UNIX  to  be  a  very  portable  opiating  system;  however,  the  many  vendor  mod¬ 
ifications  to  it  as  part  of  proprietary  infrastructures  have  resulted  in  the  proliferation  of  dif¬ 
ferent  versions.  Recent  efforts  by  major  UNIX  vendors  such  as  IBM,  Hewlett-Packard,  and 
Sun  Microsystems  have  been  made  to  try  to  unify  the  operating  systems  as  part  of  a  Com¬ 
mon  Open  Software  Environment  (COSE).  The  verdict  on  this  eleventh  hour  attempt  to 
unify  UNIX — coming  only  after  the  imminent  introduction  of  Microsoft's  Windows  NT — 
is  still  out 

This  corporate  jockeying  for  market  position  in  the  world  of  developing  stan¬ 
dards  is  not  taking  place  only  in  the  arena  of  operating  systems.  The  battle  of  coasting 
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standards  is  being  waged  full  force  in  the  area  of  networking  protocols,  user  interface  en¬ 
vironments  (UIE),  distributed  data  access,  transaction  processing  (TP)  monitors,  applica¬ 
tions  languages,  and  repositories.  The  goal  of  all  this  is  to  provide  for  the  seamless  interface 
in  a  distributed  environment  where  end-users  will  be  able  to  run  i^rplications  without 
awareness  of  the  system  software,  hardware  platform,  or  network  protocols  being  used.  To 
a  large  measure,  much  of  this  seamlessness  is  to  be  accomplished  through  the  use  of  mid¬ 
dleware  (see  middleware  discussion  in  Chapter  m),  the  comprehensive  collection  of  appli¬ 
cation  programming  interfaces  that  will  veil  the  true  system  complexity  and  heterogeneity. 
Middleware  vendors  and  products  such  as  IBM’s  System  Application  Architecture,  Open 
Software  Foundations  DCE  and  DME,  and  Microsoft’s  ODBC  and  WOSA  hope  to  com¬ 
pete  for  this  growing  market 

Thus,  the  complexity  and  confusion  stemming  from  the  movement  to  open 
systems  appear  to  be  other  manifestations  of  this  architectural  crisis  that  has  been  generated 
by  the  prodigious  growth  of  distributed  heterogeneous  computing  environment  If  the 
downsized  target  architecture  is  such  a  non-proprietary  and  heterogeneous  system,  the  risks 
associated  with  open  systems — an  unmanageable  complexity  or  commitment  to  an  inap¬ 
propriate  or  fading  standard — must  be  considered.  Furthermore,  waiting  for  resolution  of 
differing  standards  may  be  counterproductive;  comprehensive  and  clearly  dominant  stan¬ 
dards  may  never  emerge.  The  Garmer  Group  terms  “openness  in  the  absolute”  as  “non¬ 
sense”  and  in  the  long  run  predicts  a  coexistence  of  multiple  standards  with  interoperability 
between  them  [Ref.  31;p.  4]. 

c.  Technical  Expertise  and  Time  Constraints 

Finally,  two  important  and  somewhat  obvious  practical  issues  involve  the 
technical  expertise  of  personnel  and  schedule  requirements.  Often  disregarded  or  optimis¬ 
tically  estimated,  these  two  constraints  can  foil  a  downsizing  project  and  a  potential 
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business  opportunity.  The  technology  exists  to  implement  a  wide  array  of  potential  down¬ 
sizing  solutions;  only  well  trained  personnel  can  properly  choose  the  most  appropriate  of 
the  seemingly  inftnite  possibilities.  Success  in  complying  with  a  deadline,  while  still  pro¬ 
viding  a  quality  solution,  will  also  be  directly  dependent  on  the  technical  abilities  of 
personnel. 

Downsizing  from  a  mainfirame  to  a  distributed  computing  environment  re¬ 
quires  shifting  to  a  new  set  of  technical  skills.  There  is  not  so  much  a  lack  of  personnel,  as 
the  right  kind  of  personnel.  The  downsized  architectures  come  equipped  with  a  different  set 
of  tools — many  more  efficient  and  productive  than  their  mainframe  counterparts.  The  tech¬ 
nological  advances  and  advantages  made  available  by  OOP,  4GLs,  and  GUI  interfaces,  for 
example,  are  too  impressive  to  forgo.  Unfortunately,  the  mainframe  is  not  usually  the  plat¬ 
form  of  choice  for  implementing  these  tools;  as  a  result,  the  mainframe  bureaucracy  is  in¬ 
creasingly  becoming  “deskilled”  in  new  developments.  Some  IS  professionals  might  argue 
that  their  departments  cannot  afford  to  not  advance  and  leam  with  these  new  developments. 
Corporate  conferences  on  downsizing  often  compare  the  needed  skills  of  today  with  those 
of  yesterday  with  illustrations  such  as  Figure  13. 

CHANC.lNCw  SKILLS  OF  IS  DEPARTMEI^: 

Yesterday: 

•  Cobol 

•  Conventional  databases 

•  Computer  science  degree 

Today: 

.  C,  CASE,  OOP 

•  SQL  and  client/server 

•  Business  and  technical  degrees 

Figure  13:  The  Changing  Skills  of  IS  [Ref.  32:p.  214] _ 
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Strategies  to  cope  with  a  shortage  of  technical  skills  vary  from  retraining,  to 
the  hiring  of  consultants,  to  outsourcing.  The  hiring  of  outside  system  integrators  and  con¬ 
sultants  has  often  provided  efficient  and  elective  relief  to  organizations  with  an  over¬ 
whelmed  and  underskilled  staff  facing  downsizing  problems.  Increasingly,  however, 
retraining  of  internal  personnel  has  been  seen  as  the  long  term  solution  to  a  shortage  of  tech¬ 
nical  skills — in  light  of  fears  that  the  consulting  option  “may  leave  you  holding  the  bag 
once  the  new  platform  is  up  and  running”  [Ref.  33:p.  82].  A  more  conservative  strategy, 
designed  to  minimize  risk,  is  to  conduct  comprehensive  retraining  with  the  consulting  firm 
while  downsizing. 

2.  Will  the  Downsized  System  Meet  Performance  Requirements? 

When  it  comes  to  downsizing,  two  distinctive  camps  of  IS  professionals  are  sep¬ 
arated  by  a  wide  spectrum  of  performance  issues.  According  to  one  camp,  downsized  sys¬ 
tems  offer  viable  alternatives  to  the  mainframe  and  promise  sinular  performance  with  huge 
savings.  The  opportunity  to  migrate  to  smaller  systems,  that  appear  to  offer  similar  speed 
and  storage  capabilities  at  a  fraction  of  the  mainframe  costs,  is  too  attractive  for  them  to 
resist.  They  support  a  mass  exodus  to  the  distributed  computing  environment.  The  other 
camp  staunchly  defends  the  centralized  environment  and  its  track  record  for  handling  com¬ 
plex,  mission-critical  applications.  Expressing  doubt  over  the  technical  immaturity  of 
smaller  systems,  they  believe  that  only  the  mainframe  can  provide  the  full  range  of  required 
functionality  within  certain  performance  parameters. 

The  next  few  sections  will  examine  both  sides  of  the  debate.  In  the  context  of  this 
thesis,  “performance”  connotes  characteristics  such  as  flexibility  and  scalabUity,  process¬ 
ing  speed  (MIPS  rates),  throughput,  integrity  and  security,  and  availability. 
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a.  Flexibility  and  Scalability 

Computing  systems  can  evolve  and  grow  in  two  different  directions,  either 
vertically  or  horizontally.  A  vertically  expanding  system  is  one  that  grows  by  increasing 
the  resources  of  a  single  computing  node  with  the  addition  of  more  memory,  more  storage 
capability,  more  terminals,  or  more  processors.  In  contrast,  a  horizontally  expanding 
system  grows  by  adding  more  nodes  rather  than  increasing  the  resources  at  a  single 
element 

In  the  past,  the  traditional  mainframe  computing  systems  have  sometimes 
only  been  allowed  to  expand  vertically.  With  rapid  technological  advancements  in  proces¬ 
sors  and  increasing  corporate  appetites  for  more  processing  power,  typical  host  systems  be¬ 
came  outdated  and  inadequate  after  frve  productive  years.  At  this  critical  junction,  a 
corporation  that  may  only  have  needed  a  fractional  increase  in  computing  power  had  lim¬ 
ited  options  to  make  small  increments  to  capacity  (e.g.,  by  adding  more  memory,  more  I/O 
channels,  etc.).  At  some  point,  diey  needed  to  buy  entirely  new  mainframes  that  may  have 
dramatically  exceed  new  requirements.  Historically,  it  has  also  been  the  case  in  traditional 
product  lines  that  the  same  operating  systems  and  ^plication  development  environment 
(ADE)  have  not  spanned  the  range  of  computing  architectures.  Thus,  a  corporation  tiiat 
needed  to  upgrade  from  a  nud-range  computer  to  a  larger  mainframe  was  forced  to  go 
through  the  major  and  disruptive  evolution  of  migrating  the  software  to  the  new  system  and 
go  through  a  new  learning  process  for  all  IS  personnel.  This  type  of  vertical  growth  has 
three  major  limitations: 

•  potential  to  reach  systems  limit 

•  inflexibility  in  configuration 

«  potential  change  in  software  environments  [Ref.  34:p.  100] 

To  be  sure,  the  degree  of  mainframe  scalability  across  its  systems,  interoper¬ 
ability  among  systems,  and  consistency  in  its  software  and  ADE  has  grown  proportionally 
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to  the  increased  market  demand  for  such  features.  And,  to  a  considerable  extent,  these 
mainframes  characteristics  have  evolved  dramatically  since  its  early  beginnings.  Systems 
scalability  and  flexibility,  however,  tends  to  be  much  simpler  in  a  downsized  environment. 
In  terms  of  granularity  (the  size  of  the  step  that  must  be  taken  to  increase  in  functionality 
such  as  processing  power  or  storage  capability)  and  the  corresponding  price/performance 
ratio,  the  popular  consensus  is  that  the  mainframe  cannot  compete  with  a  workstation  or  PC 
in  a  distributed  environment  The  granularity  of  the  system  is  also  complemented  by  con¬ 
figuration  flexibility,  offering  the  capacity  to  increase  resources  in  different  locations  to  ac¬ 
commodate  different  IS  needs  of  the  organization. 

b»  Processing  Speed 

One  measurement  that  is  often  used  to  compare  technical  capabilities  relative 
to  costs  has  been  the  price  to  performance  ratio.  Millions  of  instructions  per  second  (MBPS) 
rates  tend  to  be  the  most  widely  used  measure  of  performance,  and  are  believed  to  represent 
the  processing  power  accomplished  by  one  or  more  processors.This  performance  measure 
is  both  so  commonly  used  and  misunderstood  that  some  suggest  a  more  appropriate  break¬ 
out  of  the  acronym  is  “meaningless  indicator  of  processing  speed.” 

Firstly,  measurements  of  MIPS  differ  between  different  architectures;  RISC 
MIPS,  IBM  S/390  MIPS  and  Intel  MIPS,  for  example,  cannot  fairly  be  judged  against  one 
another  as  all  use  different  sets  of  instructions.  Furthermore,  it  is  important  to  note  that 
MIPS  is  a  measure  of  instructions  executed  per  unit  time,  and  not  throughput.  The  MIPS 
rate  required  varies  according  to  a  number  of  factors.  Computing  machines  that  are 
comprised  of  operating  systems,  database,  and  communications  systems  may  be  required 
to  execute  more  MIPS  and  utilize  more  processing  time  to  provide  the  necessary  level  of 
functionality  than  a  system  that  does  not  have  ail  these  components.  Additionally,  some 
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application  software  and  compilers  are  written  more  efficiently  than  others  and  require  a 
fewer  number  of  instructions  to  be  executed. 

The  phenomenal  increase  in  the  MIPS  capabilities  of  smaller  machines  has 
enabled  a  network  of  workstations  in  a  downsized  environment  to  appeal  as  a  much  more 
attractive  computing  alternative  than  the  mainframe,  especially  when  comparing  4he  price/ 
performance  ratios.  For  the  majority  of  desktop  applications,  however,  MIPS  issues  are 
largely  irrelevant  in  light  of  the  minimal  CPU  execution  time  as  compared  to  the  I/O  wait 
time.  In  many  instances,  MIPS  rates  are  a  relatively  insignificant  feature  and  become  an  im¬ 
portant  factor  only  when  transactions  are  CPU-intensive  (such  as  in  scientific  applications) 
due  to  time-consuming  processing  requirements.  Thus,  MIPS  rates  should  only  become  a 
significant  performance  requireme«’.t  and  a  potential  technical  risk  when  an  application  is 
processing  intensive  and  the  CPU  becomes  the  source  of  a  bottleneck. 

The  Gartner  Group  outlines  a  similar  argument  when  comparing  mainframe 


to  PC  MIPS: 

If  you  go  to  a  typical  mainframe  shop  and  count  the  on-line  DASD  and  divide  it  by 
the  aggregate  processing  power,  you  would  find  that  there  are  between  3,000  and 
5,000  megabytes  of  data  per  MIPS.  In  a  typical  workstation,  the  ratio  is  more  like  20 
to  50  megabytes  per  MIPS.  That  is  a  two  orders  of  magnitude  difference.  By  that  ra¬ 
tio,  mai^ames  are  data-rich/MIPS-poor  platforms,  and  comparably  speaking, 
workstations  are  MIPS-rich/data-poor  platforms.  Which  is  why  you  tune  for  MIPS 
on  a  mainframe  because  it  is  the  most  constrained  resource...  We  would  never  pro¬ 
pose  to  use  dollars  per  MIPS  for  making  a  platform  choice.  It  is  an  interesting  metric 
within  a  family  of  processors,  but  is  not  interesting  between  different  types  of  pro¬ 
cessors.  [Ref.  7:p.  63] 

c.  Throughput 

The  mainframe’s  core  strength  is  often  seen  as  its  ability  to  efficiently  manage 
and  move  large  volumes  of  data.  Technically  speaking  this  translates  to  low  response  times 
and  correspondingly  high  throughput.  The  hardware,  operating  systems,  and  supporting 
software  have  all  been  optimized  to  support  this  data  management  capability  (as  discussed 
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in  Chapter  D).  The  enormous  bandwidth  and  the  ability  to  manage  multiple  complex  tasks 
simultaneously  have  become  mission-critical  elements  for  some  corporations;  these  capa¬ 
bilities  are  often  needed  to  support  bandwidth-intense  applications  that  utilize  multimedia, 
graphics,  video,  image,  and  voice.  Graphical  user  interfaces,  4GLs,  and  flexibility — 
strengths  of  the  desktop  computing  architecture — may  not  be  pertinent  in  many  cases.  Ac¬ 
cording  to  one  expert: 

The  mainframe’s  strength  is  maintaining  order  in  what  could  all  too  easily  become 
chaos  in  a  totally  distributed  environment:  assigning  order  of  admission,  changing 
data,  logging  in  updates,  and  being  prepared  for  disaster  recovery.  The  mainframe  is 
enormously  efficient  at  anticipating  an  I/O  gap  and  dealing  with  Jiother  job  simul¬ 
taneously  to  optimize  processor  performance  and  minimize  the  wait-state.  Parallel¬ 
ism,  bandwidth  and  well-developed  software  applications  give  it  incomparable 
throughput  capability.  [Ref.  35:p.  34] 

One  of  the  areas  that  the  mainframe  hardware  and  software  have  been 
groomed  for  efficiency  over  the  last  three  decades  has  been  on-line  transaction  processing 
(OLTP).  Because  MVS -compatible  programs  and  applications  have  established  a  proven 
track  record  in  protecting  data  integrity  and  guaranteeing  reasonable  response  times,  those 
systems  currently  manage  the  vast  majority  of  data  for  large  enterprises  such  as  banks,  air¬ 
lines,  and  insurance  companies.  Corporate  customers  continue  to  rely  on  the  mainframe  as 
a  platform  of  stability  for  mission-criticai  OLTP.  Admittedly,  speed,  storage  capacity,  and 
cost  factors  are  important  Yet  what  is  the  most  cost-effective  way  to  work?  An  IS  struc¬ 
tured  around  the  mainframe  has  repeatedly  shown  itself  to  be  a  system  capable  of  meeting 
incessant  demands  of  unpredictable  complexity  in  the  face  of  critical  deadlines.  Many  sys¬ 
tems  dependent  on  OLTP  demand  the  right  mix  of  MIPS,  I/^  (inpuVoutput),  and  through¬ 
put  to  maintain  their  competitive  advantage.  Many  companies  prefer  to  rely  on  the  robust 
performance  of  the  maiirframe  rather  than  venture  into  questionable  risks  associated  with  a 
downsizing  project. 
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For  years,  the  workstation’s  progress  in  the  OLTP  market  has  been  con¬ 
strained  by  its  limited  I/O  capabilities.  In  commercial  record-handling  applications,  20  to 
30  disk  accesses  may  be  required  for  each  transaction  of  medium  complexity;  a  processing 
rate  of  10  such  transactions  per  second  thus  requires  200-300  accesses  per  second.  Though 
this  rate  can  now  be  handled  by  minicomputers  and  workstations,  the  technology  has  only 
recently  become  readily  available. 

Despite  advances  in  the  I/O  capabilities  of  workstations,  the  several  hundred 
disk  accesses  per  second  achievable  by  these  servers  do  not  match  the  mainframe’s  capa¬ 
bilities.  The  10,000-15,000  I/Os  per  second  that  are  manageable  on  a  large  mainframe 
make  it  the  platform  of  choice  for  corporate  applications  that  require  such  demanding  trans¬ 
action  rates.  [Ref.  4:p.  28  &  67] 

Thus,  though  minicomputers  and  workstations  that  have  not  been  able  to 
match  top  of  the  line  mainframe  OLTP  performance  in  these  areas,  these  smaller  systems 
may  satisfy  less  demanding  OLTP  applications  with  moderate  transaction  rate  require¬ 
ments.  One  article  entitled  “PCs  Break  Into  the  OLTP  Ranks’’  explains  the  market  change: 

That  (OLTP)  picture  is  beginning  to  change.  Powerful  new  PC  hardware  and  oper¬ 
ating  systems  provide  the  performance,  security,  multiprocessing  and  multitasking 
capabilities  usually  associated  with  much  larger  systems,  making  downsized  corpo¬ 
rate  backbone  applications  possible.  And  that’s  attracted  vendors  of  transaction-pro¬ 
cessing  (TP)  monitors.  TTiese  are  the  systems  that  furnish  the  security,  data 
management,  communications  and  development  tools  needed  to  build  and  run  OLTP 
apps.  [Ref.  35:p.  32] 

The  author  of  this  article  goes  on  to  support  his  claim  by  providing  examples 
of  three  different  companies  that  have  developed  UNIX  TP  monitors  that  will  support  the 
ability  for  Macintoshes,  PCs,  and  workstations  running  Windows,  OS/2,  and  UNIX  to 
function  as  full-featured  clients.  Additionally,  fully  downsized  versions  of  IBM’s  Custom¬ 
er  Information  Control  System  (QCS) — ^the  most  pervasive  and  acclaimed  of  all  TP  mon¬ 
itors — are  now  available  on  OS/2,  IBM’s  version  of  UNIX  (ADC),  and  Windows  NT.  The 
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administrative  computing  department  at  Tulane  University  in  New  Orleans  claims  to  have 
saved  $135,000  per  year  in  maintenance  costs  alone  by  moving  only  a  portion  of  its  CICS 
applications  down  to  486-based  PCs  and  RS/6000  workstations  running  OS/2  and  AIX. 
[Ref.  35:p.  32] 

d.  Integrity  and  Security 

Decisions  to  downsize  information  systems  have  sometimes  occurred  based 
on  the  myopic  focus  on  potential  cost  savings  while  neglecting  other  important  concerns 
such  as  integrity  and  security.  Because  admissions  of  security  loopholes  are  shunned,  doc¬ 
umentation  of  case  histories  lamenting  costly  security  oversight  is  not  readily  available. 
Nevertheless,  the  lack  of  a  guarantee  of  proper  security  is  a  major  cause  for  concern  when 
downsizing.  One  major  belief  is  that  mainframe-strength  security  systems  are  simply  not 
as  readily  available — or  as  robust — in  a  distributed  environment 

The  seriousness  of  this  perceived  problem  is  compounded  by  the  fact  that  it  is 
extraordinarily  difficult  to  manage  security  in  an  environment  that  has  constantly  changing 
hardware,  operating  systems,  and  databases.  It  appears  that  the  features  that  are  so  often 
highlighted  as  an  important  advantages  of  distributed  systems — cost  savings  and  flexibili¬ 
ty — come  at  the  expense  of  security.  “When  companies  cannot  afford  all  the  security  in¬ 
volved,  they  just  don’t  talk  about  it”  commented  a  Database  Associates  professional  in 
Morgan  Hill,  California.  “People  don’t  seem  to  worry  about  it  too  much.  They  keep  their 
fingers  crossed  that  it  won’t  cause  major  problems.”  [Ref.  36;p.  25] 

While  some  organizations  are  not  willing  to  put  much  stock  in  security  at  the 
LAN  level,  others  have  already  made  their  commitments  to  downsizing  and  are  resolving 
the  security  issues  through  a  variety  of  methods.  One  of  these  methods  is  to  firewall  a  LAN 
from  external  access.  Such  an  approach  was  taken  by  Burlington  Coat  Factory  Warehouse 
in  Lebanon,  N.H.  when  it  junked  its  mainframe  in  February  1992  and  committed  itself  to 
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an  open  and  distributed  systent.  The  firm  purchased  a  central  security  system  form  Sequent 
Computer  Systems,  Inc.  in  Beaverton,  Oregon  for  six  large  Unix-based  servers  that  con¬ 
nected  several  hundred  workstations  and  several  thousand  PCs.  The  inevitable  trade-off 
they  faced  was  the  decreasing  access  with  an  increasing  level  of  security. 

Even  so,  many  corporations  feel  that  downsized  systems  can  nwet  or  exceed 
mainframe  equivalent  security.  [Ref.  36:p.  25]  In  fact,  the  Gartner  Group  also  takes  this 
position  in  a  series  about  downsizing  with  the  following  assertion: 

Downsizing  does  not  necessarily  compromise  a  system’s  general  trustworthiness... 
Although  ease  of  access,  a  secondary  objective  of  downsizing,  could  cause  exposure 
in  security  management,  the  lack  of  security  is  not  a  technics  issue.  Many  systems, 
particularly  in  the  midrange,  have  been  qualified  at  higher  Department  of  Defense 
security  levels  than  mainframes.  [Ref.  37:p.  4] 

e.  Availability 

Unpredictable  system  outages  that  prevent  access  to  mission-critical  applica¬ 
tions  can  be  very  costly  to  an  organization.  Continuous  availability,  the  expectancy  of  reli¬ 
able  service  without  system  outages,  has  almost  become  a  built-in  feature  of  the  mainftame 
environment  and  has  contributed  to  its  reputation  of  stability.  Back-up  components  auto¬ 
matically  take  over  in  case  of  failure.  The  centralized  nature  of  the  mainframe  and  the  con¬ 
centration  of  processing  resources  naturally  supports  such  availability  because  of  the  fewer 
possible  points  of  failure. 

The  issue  of  availability  in  distributes  systems,  however,  is  a  little  more  com¬ 
plex.  At  first  it  would  appear  that  a  commitment  to  distributed  computing  may  require  a 
concomitant  acceptance  of  reduced  availability  due  to  the  many  possible  points  of  failure. 
By  its  very  nature,  however,  a  distributed  system  provides  redundancy.  Even  if  a  local  pro¬ 
cessor  fails,  the  entire  system,  in  general,  will  not  fail. 

Although  the  mainframe  has  generally  enjoyed  a  better  reputation  for  provid¬ 
ing  a  high  degree  of  availability,  the  distributed  computing  environment  is  making  up  lost 
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ground  rapidly  with  advances  in  fault-tolerant  technology.  Fault  tolo'ant  technology  creates 
redundancy  within  a  distributed  architecture  by  duplicating  every  major  component  within 
one  module.  If  a  component  fails,  a  diagnostic  link  will  immediately  inform  the  service 
center  and  automatically  enable  a  substitute  component  while  the  faulty  component  is  re- 
paued  within  24  hours.  As  it  becomes  prohibitively  expensive  to  duplicate  all  components, 
redundancy  only  at  strategic  locations  becomes  a  reasonable  compromise.  Successful 
implementations  of  this  strategy  have  been  implemented  with  favorable  results.  Often  the 
fault-tolerant  system  is  used  as  a  front-end  to  a  mainframe  in  a  client/server  type 
environment 

D.  COST/BENEFIT  ANALYSIS 

The  purpose  of  the  cost/benefit  analysis  is  to  summarize  all  of  the  estimated  costs  as¬ 
sociated  with  a  downsizing  project  in  sufhcient  detail  to  give  top  decision  makers  the  ability 
to  decide  whether  or  not  to  proceed  with  the  process.  Costs  and  benefits  should  be  incre¬ 
mentally  more  accurate  with  each  succeeding  phase  of  the  SDLC.  Traditional  steps  for  per¬ 
forming  a  cost/benefit  analysis  require  estimation  of  a  variety  of  factors: 

•  cost  of  operating  the  current  system 

•  cost  of  the  downsized  system  or  proposed  system 

•  costs  associated  with  all  of  the  phases  of  the  SDLC 

•  description  of  the  intangible  costs  and  benefits 

•  basis  for  estimating  how  the  above  costs  and  benefits  will  change  in  the  next  few 
years  due  to  such  factors  as  changing  economic  and  business  trends 

•  quantification  of  the  risks  for  proceeding  or  discontinuing  the  project  [Ref.  6:p.  7 1  ] 
Putting  these  guidelines  in  the  context  of  a  downsizing  project,  the  return  on  invest- 

rrwnt  may  be  determined  by  comparing  the  conversion  costs  and  the  costs  of  operating  in 
the  new  environment  against  the  cost  of  continuing  to  operate  in  the  current  environment — 
all  over  a  set  period  of  time  (e.g.,  five  years).  This  section  will  analyze  potential  conversion 
costs  and  highlight  the  often  subtle  costs  of  operating  in  a  distributed  environment.  Because 
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not  all  downsizing-related  costs  are  readily  identifiable,  the  last  sub-section  will  examine 
some  intangible  cost  considerations. 

1.  Conversion  Costs 

The  initial  transition  costs  in  a  downsizing  program  can  vary  tremendously  ac¬ 
cording  to  the  scope  of  the  project  and  the  migration  strategy.  For  example,  if  a 
corporation’s  downsizing  strategy  is  simply  to  downsize  one  non-mission-critical  applica¬ 
tion  with  a  “surround  and  integrate”  migration  approach  (see  Chapter  QI),  then  the  conver¬ 
sion  costs  can  be  relatively  small.  A  “surround  and  integrate”  migration  strategy  leaves  the 
application  relatively  intact  on  the  host  mainframe  and  accessory  applications  are  added  as 
needed  (typically  for  a  GUI  interface).  If,  however,  the  corporate  migration  strategy  is  to 
“kill”  the  mainframe  and  to  off-load  all  applications,  the  transition  costs  will  be  dramati¬ 
cally  higher. 

TTie  conversion  costs  fall  within  two  categories:  the  cost  of  migrating  the  applica¬ 
tion  and  the  costs  of  new  hardware.  The  cost  of  migrating  the  application  will  depend  on 
the  migration  strategy.  Rewriting  the  code  for  a  mission-critical  application,  for  example, 
is  obviously  tremendously  more  expensive  and  time-consuming  than  buying  ready  to  use 
off-the-shelf  software.  IS  professionals  need  to  analyze  the  trade-offs  between  costs  and 
performance  factors  when  deciding  on  a  code  migration  strategy. 

Similarly,  the  conversion  costs  associated  with  the  purchase  of  new  hardware  will 
also  vary  significantly  according  to  the  migration  strategy.  A  “surround  and  integrate”  mi¬ 
gration  might  entail  merely  replacing  “dumb”  3270  terminals  with  intelligent  workstations 
while  keeping  the  bulk  of  the  processing  on  the  mainframe.  Such  a  move  would  certainly 
not  result  in  as  many  initial  hardware  expenses  as  a  migration  strategy  that  would  scrap  the 
mainframe.  The  Gartner  Group  estimates  that: 
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...(when)  simply  moving  applications  from  one  platform  to  another,  the  break-even 
point  usually  falls  between  two  and  four  years.  However,  if  companies  exercise  the 
“oppKJitunity  option”  to  move  to  a  more  open  environment  or  toward  distributed  or 
client/server  computing,  initial  costs  could  be  substantially  higher  and  thus  delay 
reaching  the  break-even  point  by  one  or  two  years.  [Ref.  38  :p.  9] 

2.  Operating  Costs 

Probably  a  more  difficult  challenge  than  estimating  conversion  costs  is  the  task  of 
estimating  operating  costs  in  the  new  environment.  Many  times,  downsizing  d^isions  are 
based  on  the  attractive  hardware  price/performance  ratios  offered  by  the  current  desktop 
environment  Decisions  often  do  not  account  for  other  quantitative  and  qualitative  factors 
that  are  an  integral  part  of  the  day-to  day  operations  in  a  distributed  environment  Contrast¬ 
ing  mainframes  at  $50,000  per  MIPS  to  a  UNIX  machine  at  $500  per  MIPS,  for  example, 
can  be  a  very  misleading  comparison.  The  processing  power  does  not  take  into  account  a 
myriad  of  the  other  technical  non-techrucal  issues  inherent  in  distributed  systems. 

Estimating  costs  of  distributed  systems  requires  looking  at  the  cost  of  not  just  the 
machines  themselves,  but  also  the  significant  overhead  that  accompanies  networked  archi¬ 
tectures.  Costs  grow  as  the  complexity  of  networks  grow  due  to  factors  such  as  increased 
heterogeneity,  the  additional  layers  of  software  (e.g.,  middleware)  and  expertise  necessary 
tc  support  such  diversity.  Identification  and  estimation  of  cost  elements  such  as  data  man¬ 
agement  capabilities,  labor  costs,  security,  maintenance,  ease  of  use,  and  business 
responsiveness — ^to  name  a  few — are  also  crucial  to  completion  of  an  accurate  cost/benefit 
analysis,  but  are  often  downplayed. 

a,  Life-Cycle  Cost  of  a  Downsized  System 

One  of  the  fundamental  reasons  that  is  repeatedly  cited  for  the  downsizing 
trend  is  that  traditional  mainframes  are  simply  too  expensive  compared  to  networked  work¬ 
stations,  PCs,  and  other  downsized  4tematives  that  are  currently  available  in  the  market 
The  economies  of  scale  that  once  made  the  mainframe  the  most  cost-effective  computing 
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solution  is  perceived  to  have  been  inverted.  The  focus,  howevo^,  has  primarily  been  on  the 
appealing  hardware  and  software  costs  of  downsized  systems  and  has  tended  to  ignore  full 
life-cycle  costs  of  downsized  systems. 

(1)  Hardware  costs.  Hardware  components  represent  perhaps  the  most  visible 
and  tangible  costs.  Overhead  transparencies,  similar  to  the  one  in  the  Table  4,  frequently 
illuminate  executive  boardrooms  to  illustrate  price  differences  and  trends  of  initial 
hardware  costs. 


Table  4:  PRICES:  MAINFRAME  AND  WORKSTATION  [Ref.  9] 


Cost  Per 

Mainframe 

Workstation 

MIPS 

$100,000-$ 150,000 

typically  less  than  $500 

Megabyte  Memory 

$200a-$4,000 

typically  less  than  $100 

Megabyte  Disk 

$5-$10 

$l-$2 

While  these  price/performancc  ratios  of  desktop  systems  are  impressive, 
desktop  hardware  components  are  becoming  obsolete  at  a  faster  rate  than  mainframe  tech¬ 
nology.  Replacing  hundreds  or  thousands  of  desktop  computers  in  very  large  organizations 
every  few  years  can  become  a  very  expensive  proposition.  Even  with  the  frequent 
replacements  of  workstations,  the  hardware  costs  of  desktop  systems  really  represent  only 
a  narrow  slice  of  the  total  IS  budget  While  Table  4  illustrates  the  current  unit  costs.  Table 
S  shows  the  historical  price  and  performance  trends  for  the  workstation,  minicomputer  and 
mainframe.  Again,  though,  such  tables  generally  tend  to  illustrate  only  those  aspects  of 
computing  systems  that  are  discrete  and  readily  quantifiable.  End-users  tend  to  be  more  im¬ 
pressed  by  large  numbers  representing  speed  and  storage  capabilities  than  with  qualitative 
explanations  of  security  and  reliability.  Thus,  while  Table  5  dramatically  depicts  the 
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industry’s  downsizing  direction  and  potential,  it  does  an  inadequate  job  in  illustrating  other 
important  attributes  of  both  PC  and  mainfranK  systems  and  their  full  life  cycle  costs. 
Table  5:  PRICE  AND  PERFORMANCE  TRENDS  [Ref.  9] 


Workstation 

Minicomputer 

Mainframe 

1993 

1981 

1971 

MIPS 

50 

2.0 

1.0 

Off-line  Storage  (MB) 

2000 

100 

20 

Operating 

multi-user. 

multi-user 

single-user 

System 

multi-processing 

single  processing 

single  processing 

Internal  Memory  (MB) 

32 

8 

2 

Task  Capacity  (tasks) 

16 

8 

4 

Cost 

$5,000 

$100,000 

$1,000,000 

(2)  Software  costs.  Cost  comparisons  of  development  and  maintenance  of 
mainframe  versus  desktop  software  have  highlighted  significant  cost  differences  that  are 
commonly  perceived  to  favor  smaller  systems.  The  Consolidated  Insurance  Group,  prior  to 
downsizing  to  a  PC  LAN,  utilized  a  $200,000  mainframe-based,  general-ledger  program  to 
maintain  its  accounts.  After  downsizing,  the  insurance  company  switched  to  a  $595  off-the- 
shelf  program  to  perform  the  same  functions — a  300  to  1  price  advantage  over  the 
mainframe  version  [Ref.  6:p.  5].  Other  comparisons,  such  as  the  following  observation, 
have  noted  price  disparities: 

In  one-on-one  comparisons  of  packaged  software  between  mainframes  or minis  and 
PCs,  the  price  comparison  is  so  vast  as  to  be  almost  ludicrous.  Typical  PC  packages 
cost  from  $50  to  $500;  typical  mini  and  mainframe  packages  cost  from  $5000  to 
$50,000.  The  100-to-l  advantage  in  cost  is  a  good  rule  of  thumb.  [Ref.  6:p.  57] 


There  is  little  dispute  over  the  cost  advantages  of  a  single  software  package 
for  a  desktop  environment  over  one  built  for  a  mainframe  system.  Organizations,  however, 
need  to  make  one  additional  consideration.  How  many  individual  software  packages  do 
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they  need  to  buy  to  support  hundreds  or  thousands  of  networked  desktops?  A  100-to- 1  cost 
advantage  quickly  disappears  when  large  quantities  of  software  packages  with  documenta¬ 
tion  are  purchased  to  meet  corporate- wide  requirements.  Furthermore,  because  of  the  short¬ 
er  life-cycle  of  desktop  software,  organizations  may  find  themselves  spending  money  to 
support  periodic  upgrades  to  new  and  improved  versions.  Acquisition  of  site  licenses  can 
alleviate,  but  not  remedy,  this  situation. 

(3)  Full  Life-Cycle  Costs.  Convincing  price  comparisons  of  hardware  and 
software  costs  are  often  used  to  help  justify  moving  to  smaller  systems  throughout  industry 
journals  and  trade  shows.  The  focus  tends  to  be  on  hardware  and  software — capital  costs — 
not  the  entire  life  cycle.  One  study  performed  by  the  Gartner  Group  helps  refute  the  impor¬ 
tance  of  capital  costs.  In  it,  the  Gartner  Group  estimated  the  average  five-year  life  cycle  of 
an  average  PC  in  a  corporate  environment  to  be  $40, 1 24,  with  capital-related  costs  account¬ 
ing  for  only  15%  of  the  total  life-cycle  costs.  The  other  85%  percent  of  the  costs  were  per¬ 
sonnel  costs,  related  to  administrative  and  technical  support  as  well  as  end-user  operations. 
Figure  14  illustrates  these  findings.  [Ref.  37  :p.  6-7] 


Total  Cost 

$40,124 

(100%) 

•  Capital-related 

$5,886 

(15%) 

•  Labor-related 

$34,238 

(85%) 

—  Administration 

$5,505 

(14%) 

—  Technical  Support 

$6,040 

(15%) 

—  End-user  Operations 

$22,693 

(56%) 

The  Gartner  Group  attributed  56%  of  the  total  costs,  by  far  the  most  signifi¬ 
cant  portion,  to  labor  related  to  “end-user  operations.”  End-user  costs  are  incurred  because 
there  may  be  fewer  formal  IS  billets,  and  so  the  functions  that  were  formerly  being  per¬ 
formed  by  the  technicians  are  now  performed  by  end-users  at  the  departmental  level.  Ac¬ 
cording  to  a  noted  expert,  “As  a  distributed  system  evolves,  users  may  assume  a  role  in  its 
design  and  operation.  As  desirable  as  this  is,  it  also  can  result  in  a  substantial  expenditure 
of  bootlegged  time  that  is  not  explicitly  identified  as  a  development  cost”  [Ref.  39:p.  15]. 
Thus,  IS  personnel  costs  on  paper  may  appear  to  be  diminishing,  when  in  reality,  the  costs 
are  merely  being  shifted  to  the  end-users.  End-user  operational  costs  include  the  following: 

•  Data  management  This  refers  to  the  end-user  requirement  to  perform  a  large  de¬ 
gree  of  data  manipulation  formerly  done  by  IS  personnel — such  as  backup,  con¬ 
version,  compression/decompression,  transfer,  encryption,  organization,  and 
sharing  of  files. 

•  Application  development  Ranging  from  spreadsheet  work  to  coding  using  lower 
level  languages,  more  and  more  informal  application  development  is  being  done 
by  the  end-user  to  assist  in  job-related  tasks. 

•  Formal  learning.  Classroom  training  time  is  often  needed  to  get  familiar  with  ei¬ 
ther  applications  or  development  tools. 

•  Casual  learning.  On-the-job  learning  substitutes  for  formal  learning  when  formal 
training  is  not  available. 

•  Peer  support.  The  office  PC  guru  spends  much  of  his  or  her  time  substituting  as  the 
“help  desk,”  taking  that  individual  away  from  primary  duties. 

•  Supplies.  The  purchase  of  expendable  materials  at  the  end-user  level  to  include 
everything  firom  paper  to  diskettes. 

•  “Futz”  factor.  The  time  squandered  unproductively  in  an  application,  whether  it  is 
playing  with  different  fonts  or  conducting  person^  business.  [Ref.  37:p.  6-7] 

b.  Hidden  Overhead  Costs  for  Downsized  Systems 

In  general,  mainframe-based  systems  can  be  classified  as  capital  intensive 
whereas  PC  LANs  can  be  labelled  as  more  labor  intensive.  In  a  centralized  architecture,  all 
major  functions  can  be  performed  at  the  data  center;  core  teams  of  highly  specialized  and 
trained  personnel  are  easily  capable  of  maintaining  applications  and  system  functionality 
for  thousands  of  users.  A  distributed  environment  shifts  many  of  those  centralized 
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functions  to  the  department  and  end-user  level.  According  to  studies,  some  distributed  sys¬ 
tems  (client/server)  will  require  a  support  person  for  every  35  users,  with  support  costs  be¬ 
ing  three  times  as  much  as  the  hardware  and  software  [Ref.  40:p.  28].  Table  6  reflects  the 
relationship  between  labor  and  coital  cost  as  the  computing  platform  changes.  - 


Table  6:  LABOR  &  CAPITAL  COSTS  OF  PLATFORMS  [Ref.  41  :p.  8] 


Platform 

Labor 

O^ital 

Mainfiame 

30% 

70% 

Minicomputer 

40% 

60% 

PC  (Enterprise  Network) 

61% 

39% 

PC  (LAN  Work  Group) 

69% 

31% 

PC  (Stand-alone) 

85% 

15% 

As  suggested  by  the  full  life-cycle  cost  distribution  in  Figure  14,  distributed 
environments  sometimes  come  with  hidden  price  tags.  The  Gartner  Group  categorizes 
many  of  these  hidden  elements  as  management  and  control  functions  such  as  availability, 
performance,  backup  and  recovery,  security,  system  management,  network  management, 
disaster  recovery,  capacity  planning,  and  change  management  [Ref.  41  :p.  8].  It  may  be  the 
case  that  there  is  no  need  for  some  of  these  requirements,  and  thus,  the  hidden  overhead 
may  not  be  as  damaging.  If,  however,  these  hidden  costs  do  represent  essential  functions  of 
an  organization's  infrastructure  and  they  are  not  adequately  addressed  in  the  cost  estimates, 
a  distorted  picture  of  the  true  costs  can  result  (Figure  15). 

3.  Intangible  Benefits 

Intangible  benefits  refer  to  those  attributes  of  desktop  systems  that  may  be  ex¬ 
tremely  beneficial,  but  hard  to  express  in  monetary  terms.  In  fact,  in  the  long  run,  these  ben¬ 
efits  may  be  a  more  significant  driver  in  fueling  the  downsizing  trend  than  the  perception 
of  cost  savings.  While  corporate  end-users  are  becoming  accustomed  to  the  new  desktop 


control  and  ease-of-use  of  these  new  desktop  tools,  corporate  officials  increasingly  realize 
the  strategic  necessity  of  greater  technological  flexibility  and  responsiveness  to  change. 
Yet  how  does  one  measure  the  benefits  or  costs  of  attributes  like  desktop  control,  techno¬ 
logical  flexibility,  and  greater  responsiveness  to  new  business  requirements?  Undeniably, 
these  factors  are  perceived  to  be  critical  to  many  organizations — but  how  critical,  and  what 
is  It  worth?  The  fact  remains  that  measuring  any  increase  or  decrease  in  productivity  as  a 
result  of  these  intangible  benefits  is  a  very  difficult  task. 

Some  believe  that  downsizing  is  a  revolutionary  process  that  cannot  be  cost-jus¬ 
tified  with  traditional  IS  cost-estimating  procedures.  They  argue  that  “traditional  IS  costing 
methods  are  based  on  the  rules  of  a  bygone  era  in  which  mass  production  manufacturing 
served  as  the  model  for  cost  justification”  and  that  applying  old  methodologies  to  try  to 
cost-justify  downsizing  is  simply  inappropriate  [Ref.  42].  Others  agree  tlsat  downsizing  is 
a  revolutionary  process,  but  that  a  cost/benefit  analysis  becomes  that  much  more  significant 
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because  of  the  importance  of  the  intangible  and  unquantifiable  costs  and  benefits.  Accord¬ 
ing  to  the  Gartner  Group: 


Downsizing  is  often  viewed  as  a  process  that  stems  naturally  from  hardware  becom¬ 
ing  smaller,  less  expensive,  and  easier  to  maintain.  In  reality,  downsizing  is  part  of 
a  technology  restructuring  that  formalizes  a  fundamental  shift  of  ownership  of  IT  as¬ 
sets.  Decisions  require  a  fully  burdened  life-cycle  cost  analysis,  especially  because 
a  substantial  amount  of  spending  occurs  through  end-user  activities  that  are  not  part 
of  the  formal  IS  budget  [Ref.  38;p.  6] 

Undoubtedly,  cost-justifying  downsizing  is  an  extremely  complex  process  that 
may  require  non-traditional  methods.  And  certainly,  the  qualitative  and  largely  unquantifi¬ 
able  factors  should  be  weighted  equally  with  discrete  and  quantitative  ones.  Given  the  lim¬ 
ited  scope  of  this  thesis  and  the  almost  unwieldy  task  of  a  complete  cost-justification,  this 
chapter  will  not  attempt  to  outline  specific  techniques  of  full-blown  cost-justification — 
which  would  inevitably  require  weighting  the  indirect  benefits  and  incorporating  them  with 
those  features  that  are  directly  measurable. 
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V.  FRAMING  THE  DOWNSIZING  ISSUES  FOR  DOD  AND  ONI 


Much  of  the  focus  of  this  thesis  so  far  has  been  on  providing  a  corporate  perspective 
of  downsizing  issues.  Earlier  references  to  business  needs  and  processes,  organizational 
support,  and  cost  savings  have  frequently  been  mentioned  in  the  context  of  the  civilian 
agencies  competing  in  the  private  market  Despite  the  focus  on  the  corporate  world,  draw¬ 
ing  boundaries  between  DoD  organizations  and  the  private  sector  to  isolate  differences  is 
largely  unnecessary.  DoD  organizations  are  unique  in  many  respects,  but  for  the  most  part 
IT  trends  mirror  those  of  its  corporate  counterparts. 

This  chapter  will  attempt  to  “frame”  and  summarize  the  key  downsizing  issues  for 
DoD  organizations  such  as  the  Office  of  Naval  Intelligence  (ONI).  TTiis  will  include  an  out¬ 
line  of  the  DoD  policies  and  federal  initiatives  that  have  created  a  virtual  mandate  to  down¬ 
size — and  how  DoD  organizations  are  responding  to  that  mandate.  The  last  part  of  this 
chapter  will  highlight  key  issues  for  ONI  by  encapsulating  “corporate  lessons  learned.” 
This  portion  will  surrunarize  the  thesis,  hopefully  giving  top  managers  general  guidelines 
with  which  they  can  intelligently  plan  a  downsizing  strategy  and  make  key  decisions. 

A.  THE  DEPARTMENT  OF  DEFENSE  (DOD)  MANDATE 

DoD  and  ONI  are  in  the  process  of  responding  to  the  same  business  pressures  shared 
by  private  industry.  Customers  are  demanding  better  service.  Budgets  are  declining.  Sub¬ 
sequent  pressures  to  “do  more  with  less”  and  “work  smarter,  not  harder”  are  forcing  orga¬ 
nizations  to  re-think  the  way  they  do  business.  The  most  common  response  to  this 
challenge,  both  in  the  corporate  world  and  government,  has  been  to  use  IT  to  reengineer 
and  redefine  business  processes  and  achieve  greater  efficiencies  with  tremendous  cost 
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savings.  Where  does  the  trend  of  downsizing  information  systems  fit  into  this  picture?  The 
downsizing  trend  is  a  manifestation  of  efforts  to  implement  diis  vision. 

The  federal  government  and  DoD,  responding  to  pressures  to  utilize  IT  more  ef¬ 
ficiently,  have  begun  a  series  of  initiatives  to  fight  the  complexity  and  costs  of  cpmputing 
and  streamline  government-wide  information  processing. 

1.  Corporate  Information  Management  Program 

One  of  the  most  visible  initiatives  of  DoD  in  recent  years  has  been  the  Corporate 
Information  Management  (CIM)  program.  CIM  seeks  to  help  DoD  managers  and  military 
commanders  make  best  use  of  their  information  by  calling  for  the  restructuring  and  realign¬ 
ment  of  the  entire  information  infrastructure  of  the  Department  of  Defense. 

The  objectives  of  CIM  sound  remarkably  similar  to  those  of  the  business  reengi¬ 
neering  and  the  total  quality  movement  (Chapter  IV).  CIM’s  goal  is  to  optimize  business 
processes  by  identifying  business  improvement  opportunities,  promoting  a  common  under¬ 
standing  of  business  rules  across  departments,  and  then  designing  systems  to  support  the 
way  business  is  done.  To  complement  and  support  these  goals,  CIM  strongly  ^vocates 
standardization,  interoperability,  shared  data,  reusable  software,  and  modular  applications. 
Examples  of  implementations  of  CIM  concepts  include  attempts  to  consolidate  some  of 
DoD  data  centers;  one  phase  included  consolidation  of  428  data  centers  into  52  mega¬ 
centers.  A  more  recent  CIM  initiative  has  been  for  DoD  to  consolidate  21,(X)0  of  its  legacy 
applications  into  about  547  interim  systems  by  1999.  The  payoff  for  such  bold  initiatives 
include  significant  cost  reductions  because  of  fewer  systems,  less  maintenance,  shorter  de¬ 
velopment  times,  and  lower  development  costs.  According  to  Paul  Strassman,  former  di¬ 
rector  of  Defense  Information  and  a  leading  advocate  of  the  CIM  program: 

The  savings  are  everywhere,  because  savings  are  [achieved],  by  and  large,  by  doing 
business  process  redesign...  We  have  a  formal  process  for  looking  at  business  pro¬ 
cesses — ^who  says  what  to  whom,  who  passes  paper  to  whom — and  then  doing  value 


90 


analysis.  And  [we  have  found]  whole  functions  which  have  grown  ovw  30  years 
which  are  not  necessary  anymore.  [Ref.  43:p.  107] 

Though  CEM  efforts  such  as  data  consolidation  hint  of  centralized  processing, 
Strassman  is  very  much  a  believer  in  distributed  architectures: 

Y  ou  must  also  undo'stand  that  we  also  believe  in  client/server.  While  we  are  consol¬ 
idating  the  main  files,  at  the  same  time  we’re...  decentralizing  application  processing 
into  a  client/server  environment  [Ref.  43:p.  108] 

2.  Defense  Management  Review  Directive  (DMRD)  918 

To  support  the  concepts  defined  by  CEM,  in  early  1993  DoD  issued  a  Defense 
Management  Review  Decision  (DMRD)  918  that  mandates  DISA  to  design,  develop, 
maintain,  and  support  a  Defense  Information  Infrastructure  (DU)  that  will  help  DoD  create 
a  multi-service,  seamless,  end-to-end  network  based  on  an  open  system,  multi-level  secu¬ 
rity,  client/server  environment  According  to  the  director  of  the  Pentagon’s  Center  for  In¬ 
formation  management  the  ideal  DO  will  create  an  “infosphere”  that  will  be  capable  of 
providing  military  personnel  with  integrated  services  for  voice,  data,  and  video  from  a  sin¬ 
gle  terminal.  Paul  Strassman  says  DO  is  to  DoD  as  the  skeleton  is  to  the  body — DD  will 
essentially  serve  as  the  backbone  on  which  the  defense  databases,  the  CIM  technical  refer¬ 
ence  model,  the  data  dictionary,  and  systems  will  hang.  [Ref.  44:p.  3] 

The  DMRD  918  strategy  for  streamlining  the  DoD  information  infirastructure 
does  not  rely  on  merely  building  a  conceptual  framework.  For  example,  besides  working 
towards  creating  a  service- wide  information  infrastructure,  DMRD  918  also  seeks  to  align 
automatic  data  processing  (ADP)  efforts  through  consolidation  of  many  of  independent  and 
service-specific  functions  at  DISA.  These  changes  are  being  coordinated  by  new  DISA  di¬ 
rector,  Ll  Gen.  Alonzo  Short  Jr.,  who  believes  “[cjhange  is  not  going  to  stop.  IT  applica¬ 
tions  must  be  the  directing  force  as  you  set  to  add  value  to  your  products  and  services... 
There  has  to  be  a  transition  from  high  volume  to  high  value”  [Ref.  4S:p.  IS].  As  originally 
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estimated,  this  new  realigned  infrastructure  has  projected  savings  of  $4.5  billion  across  all 
the  services  for  the  period  from  1993  to  1999. 


3.  National  Performance  Review  (NPR) 

In  releasing  the  report  of  the  National  Performance  Review  (NPR)  in  September 
1993,  Vice  President  Gore  helps  to  validate  ongoing  DoD  efforts  to  do  more  with  less  by 
streamlining  IS  processes,  reducing  redundancy,  and  encouraging  interoperability.  Entitled 
From  Red  Tape  to  Results,  Creating  a  Government  that  Works  Better  &  Costs  Less,  the 
NPR  issues  a  clarion  call  for  using  IT  to  reengineer  business  processes  and  obtain  radical 
improvements  in  government  efficiency: 

Washington’s  attempts  to  integrate  information  technology  into  the  business  of  gov¬ 
ernment  have  produced  some  successes  but  many  costly  failures.  Many  federal  ex¬ 
ecutives  continue  to  overlook  information  technology’s  strategic  role  in 
reengineering  agency  practices.  Agency  information  resource  management  plans 
aren’t  integrated,  and  their  managers  often  aren’t  brought  into  the  top  realm  of  agen¬ 
cy  decision-making.  Modernization  programs  tend  to  degenerate  into  loose  collec¬ 
tions  of  independent  systems  solving  unique  problems.  Or  they  simply  automate, 
instead  of  improve,  how  we  do  business.  [Ref.  46] 


The  report  suggests  extensive  use  of  IT  to  create  a  government  that  wracks  better 
and  costs  less: 

With  computers  and  telecommunications,  we  need  not  do  things  as  we  have  in  the 
past.  We  can  design  a  customer-driven  electronic  government  Aat  operates  in  ways 
that,  10  years  ago,  the  most  visionary  planner  could  not  have  imagined...  [Ref.  46] 


As  everyone  knows,  die  computer  revolution  allows  us  to  do  things  faster  and  more 
cheaply  than  we  ever  have  brfore.  Savings  due  to  consolidation  and  modernization 
of  the  information  infi^tructure  amount  to  $5.4  bUlion  over  5  years.  [Ref.  46] 

B.  RESPONDING  TO  THE  MANDATE 

Undoubtedly,  the  federal  initiatives  that  are  in  place  are  a  clear  edict  for  the  use  of  IT 
to  “reinvent”  government  and  make  it  do  more  for  less  money.  Though  die  problems  of 
government  are  well  identified  and  the  vision  of  the  future  is  clear,  the  procedures  for 
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achieving  these  objectives  are  vague.  Promises  of  a  “customer-driven  electronic  govern¬ 


ment”  and  DoD  “infospheres”  all  too  often  paint  a  rosy  future  without  adequate  discussion 
of  procedural  implementation. 

Ultimately  however,  in  terms  of  IT,  the  implications  of  these  federal  initiatives  are 
much  the  same  as  in  the  corporate  world.  One  of  the  inevitable  responses  to  the  mandate  is 
to  “downsize”  or  “rightsize”  organizations,  taking  advantage  of  new  and  faster  technolo¬ 
gies  and  more  flexible  architectures  such  as  client/server. 

Viewed  somewhat  as  a  panacea  to  government  ineffectiveness  and  inefficiency,  the 
downsizing  of  information  systems  is  already  a  pervasive  federal  trend — not  necessarily  in 
response  to  the  federal  directives.  DoD  and  otho^  federal  agencies  are  off-loading  their  ap¬ 
plications  from  the  mainframes  to  distributed  computing  environments  at  much  the  same 
pace  of  the  civilian  sector.  Of  all  federal  IT  executives  surveyed  in  a  1993  downsizing 
study,  84  percent  of  them  revealed  that  their  organizations  planned  to  migrate  to  a  client/ 
server  architecture  [Ref.  47:p.  16].  Such  responses  support  other  studies  of  declining  fed¬ 
eral  mainframe  usage  and  estimates  of  a  continuing  exodus  towards  desktop  computing. 
Findings  from  one  study  regarding  mainframe  usage  are  illustrated  in  Figure  16. 
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C.  HIGHLIGHTING  CORPORATE  “LESSONS  LEARNED” 

In  light  of  the  exodus  to  smaller  systems  and  open,  distributed  architectures  such  as 
client/server,  downsizing  of  IS  is  too  often  perceived  as  the  “easy  answer”  to  federal  prob¬ 
lems.  As  the  corporate  world  has  discovered,  however,  while  downsizing  can  resolve  some 
issues,  it  also  has  the  potential  of  opening  up  a  Pandora’s  Box  if  done  based  on  faulty  or¬ 
ganizational,  technical,  and  cost  assumptions. 

At  a  June  1993  symposium  on  Rightsizing  in  the  Federal  Government,  keynote 
speaker  Congressman  Charlie  Rose  (D-N.C.)  warned  that  the  growth  of  the  distributed 
environment  could  lead  to  administrative  nightmares  for  agencies.  Rose  said  that  the  com¬ 
bination  of  powerful  desktop  systems  armed  with  rudimentary  programming  knowledge 
could  create  “the  new  anarchy  of  the  masses  in  computing.”  He  also  cautioned  the  audience 
about  the  functions  they  might  be  inadvertently  abandoning  in  a  downsized  environment, 
pointing  out  the  mainframe  strengths  in  the  area  of  systems  and  network  management  and 
security.  Concerned  about  this  possible  lack  of  control.  Rose  stated  that  “multiple  forms  of 
bad  data”  and  problems  with  viruses  “could  be  the  legacy  of  the  new  structure.”  As  a  final 
note,  he  advised  “Let’s  not  throw  out  all  of  the  lessons  we  learned  from  the  mainframe  era.” 
[Ref.  47:p.  16  &  20] 

Thus,  as  ONI  and  other  DoD  agencies  try  to  respond  to  pressures  to  “do  more  with 
less”  and  examine  the  option  of  downsizing  information  systems  from  a  mainframe  envi¬ 
ronment  to  distributed  architectures  such  as  client/server,  strong  consideration  needs  to  be 
given  to  several  key  issues  that  have  been  covered  in  this  thesis.  The  following  paragraphs 
use  key  findings  of  this  thesis  to  summarize  important  considerations  when  downsizing. 

1.  Organizational  Considerations 

•  Recognize  organizational  implications  of  distributed  computing  before  downsiz¬ 
ing.  Distribution  of  computing  resources  may  be  inherently  more  suitable  in  some 
organizations  than  others  depending  on  organizational  operations  and  enterprise- 
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wide  interdependencies.  Although  technical  considerations  are  critical,  they  should 
not  be  the  prime  force  behind  a  system  architecture. Additionally,  end-users  should 
be  given  special  consideration  and  a  voice  in  the  distribution  and  utilization  of 
computing  resources. 

•  Understanding  of  business  needs  is  critical.  IT  can  only  be  a  strategic  asset  to  the 
degree  that  it  supports  the  corporate  strategy.  For  downsizing  to  work,  planning  ef¬ 
forts  must  ensure  that  the  downsized  product  is  relevant  to  the  business  needs. 
Analysis  of  critical  success  factors  in  strategic  IS  planning  may  serve  as  an  essen¬ 
tial  first  step. 

•  Optimize  business  processes  before  automation.  All  aspects  of  a  system  must  be 
broken  down  to  their  individual  components  to  the  point  where  all  linkages,  inter¬ 
dependencies,  and  relationships  between  parts  are  clearly  understood.  All  ineffi¬ 
ciencies  in  the  system  should  be  removed,  allowing  only  the  procesMS  that  add 
value  to  remain.  Streamlining  and  possible  automation  of  these  remaining  process¬ 
es  ensures  maximum  efficiency  and  productivity. 

•  Top  management  support  is  a  prerequisite.  Before  proceeding  too  quickly  with 
any  downsizing  plans,  it  is  an  absolute  necessity  to  ensure  that  top  corporate  offi¬ 
cials  have  “bought  off”  on  the  idea.  Downsizing  is  as  much  a  political  issue  as  a 
technical  issue.  Commitment  is  crucial  in  light  of  a  potentially  difficult  migration 
process  full  of  volatile  cultural  and  social  upheaval. 

•  Resistance  to  change  should  be  anticipated  and  managed.  Downsizing  will  require 
change — and  inevitably,  change  will  provoke  resistance.  Unless  prot^tive  steps 
are  taken  to  counter  potentially  negative  reactions,  the  forces  of  resistance  can 
work  to  undermine  any  downsizing  initiatives.  Thus,  the  CIO  and  CEO  must  ac¬ 
knowledge  these  predictable  responses  and  work  in  concert  to  match  each,  in  turn, 
with  a  countermeasure. 

•  Some  centralized  direction  is  essential.  Considerable  centralized  direction  fi-om 
top  IS  management  is  critical  to  guide  the  downsizing  process;  this  is  particularly 
true  with  respect  to  the  IS  infiastructure. 

2.  Architectural  and  Technical  Considerations 

•  Client/server  architecture  promises  the  most  flexibility.  In  the  client/server  model, 
a  network  composed  of  mainfirames  (to  include  mid-range  computers)  and  power¬ 
ful  desktop  computers  can  all  play  critical  roles.  The  varying  degrees  of  client/ 
server  difierent  models  and  “shades”  of  client/server  computing  allow  data  presen¬ 
tation,  application  location,  and  data  management  to  be  hosted  on  die  most  appro¬ 
priate  platform.  Performance  can  be  optimized  by  the  shifting  and  redeployment 
of  data  resources  and  computing  powCT  according  to  task  requirements  and  system 
strengths. 

•  Heterogeneous  client/server  architectures  also  promise  complexity.  The 
inevitable  by-product  of  technological  flexibility  has  been  complexity.  The  trend 
has  moved  computing  fi’om  an  era  of  manageable,  homogeneous  computing  on 
monolithic  systems  to  an  era  of  unmanageable,  heterogeneous,  network^  systems 
creating  an  architectural  crisis  of  sorts. 

•  The  mairframe  can  play  critical  roles  in  a  client/server  environment.  Many  IS  ex¬ 
perts  believe  that  the  mainframe’s  role  will  evolve  this  decade  in  new  ways  that  are 
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synergistic  with  the  boom  in  distributed  computing.  New  technologies  can  supple¬ 
ment  rather  than  displace  older  ones  with  the  mamframe  being  particularly  well- 
suited  as  an  enterprise  hub  in  the  areas  of  data  management  and  networking 
management. 

•  Open  systems  remain  to  be  one  of  the  biggest  challenges.  Building  a  comprehen¬ 
sive  and  absolute  set  of  standards  that  will  allow  construction  of  integrated  systems 
and  will  allow  interoperability  of  systems  and  portability  of  applications  is  unreal¬ 
istic.  Gartner  Group  predicts  a  coexistence  of  multiple  standa^s  with  interopera¬ 
bility  between  them. 

•  The  role  of  middleware  is  inextricably  linked  to  open  systems.  Middleware,  with 
its  goal  of  transparent  software  services,  will  continue  to  be  a  critical  component 
in  reaching  any  virtually  homogeneous  architecture. 

•  Rapid  Application  Development  tools  (RAD)  can  significantly  increase  productiv¬ 
ity.  RAD  tools  such  as  4GLs  can  offer  significant  tenefits  to  increase  application 
development  productivity.  Though  some  believe  that  4GL’s  are  too  proprietary,  do 
not  permit  portability,  and  are  unsuitable  for  complex  programs  requiring  intricate 
data  handling,  some  4GL  tools  have  proven  otherwise. 

•  Selecting  an  appropriate  downsizing  candidate  is  crucial  to  project  success.  Many 
IS  personnel  use  heuristics  such  as  high  maintenance  costs  and  low  mission-criti¬ 
cality  to  guide  their  decisions.  Other  factors  such  as  the  actual  structure  of  the 
code,  however,  can  significantly  affect  downsizing  feasibility  as  well. 

•  Migration  strategy  is  as  important  as  the  downsizing  decision  itself  Organizations 
ne^  to  decide  to  either  (1)  grow  with  their  traditional  mainframes,  (2)  fade  out  the 
mainframe  while  preparing  replacement  systems,  or  (3)  kill  the  mainframe  as 
quickly  as  possible— commitment  to  a  global  strategy  should  help  guide  other  de¬ 
cisions. 

•  Downsizing  can  mean  trading  systems  maturity  and  integrated  services  of  larger 
systems  for  flexibility,  openness,  and  unintegrated  services  of  distributed  systems. 
Despite  their  proprietary  nature  and  expense,  many  corporations  are  unwilling  to 
move  mission-critical  systems  to  an  unproven,  immature  desktop  environment. 
The  services  provided  by  mainframe  systems  management  tools  are  perceived  to 
be  more  developed  and  tested  than  in  a  client/server  environment. 

•  Security  issues  should  not  be  an  afterthought.  Neglecting  such  important  issues  as 
security  and  integrity  can  result  in  serious  loopholes  in  the  information  system. 
Despite  rapid  advances,  the  perception  is  that  mainframe-strength  security  systems 
are  simply  not  as  available — or  as  robust — in  a  distributed  environment 

•  Throughput  capabilities  remain  a  major  strength  of  the  mairframe.  The  main¬ 
frame  has  been  optimized  to  support  high  volume  and  intricate  data  management 
with  its  enormous  bandwidth  and  the  ability  to  manage  multiple  complex  tasks. 
The  most  advanced  and  developed  desktop  systems  are  just  beginning  to  compete 
with  the  mainframe  in  this  area. 

3.  Cost  Considerations 

•  Cost/bentfit  analysis  must  include  conversion  costs  and  costs  of  operating  in  new 
environment.  Often  the  costs  associated  with  conversion  are  overshadowed  by 


% 


promises  of  cost  savings  in  a  new  environment  Up-ffont  conversion  costs  to  dis¬ 
tributed  systems  can  represent  a  sizable  investment 

•  Conversion  costs  will  vary  tremendously  depending  on  the  candidate  application 
for  downsizing  and  the  migration  strategy.  If  the  corporate  migration  strategy  is  to 
“kill”  the  mainfirame  and  to  off-load  all  applications,  the  conversion  costs  may  be 
dramatically  higher  than  with  a  “surround  and  integrate”  strategy. 

•  Costs  of  operating  in  a  distributed  environment  are  often  grossly  underestimated. 
Focus  on  the  des^p  capital-related  hardware  and  software  costs  to  the  exclusion 
of  persotmel  and  systems  management  costs  can  result  in  a  distorted  cost  analysis. 

•  Contrasting  costs  of  mainframes  to  desktop  systems  in  terms  of  price-to-perfor- 
mance  rations  can  be  a  very  misleading  comparison.  The  processing  power  does 
not  take  into  account  the  true  meaning  of  MPS,  nor  does  it  account  for  a  myriad 
of  the  other  technical  and  non-technical  issues  that  comprise  a  significant  share  of 
an  IS  budget. 

•  In  terms  of  costs,  mairrframes  tend  to  be  capital  intensive;  desktop  systems  tend  to 
be  labor  intensive.  Gartner  Group  estimates  that  the  capital-related  costs  of  the  av¬ 
erage  five-year  life  cycle  of  an  average  PC  in  a  corporate  environment  accounts  for 
only  15%  of  the  total  costs;  the  other  85%  percent  of  the  costs  are  personnel  costs, 
related  to  administrative  and  technical  support  as  well  as  end-user  operations. 

•  Cost-justifying  downsizing  is  an  extremely  complex  process  that  may  require  non- 
traditional  methodologies.  Because  many  intangible  factors  such  as  “ease-of  use” 
and  flexibility  can  yield  significant  benefits,  the  qualitative  and  largely  unquanti- 
fiable  factors  should  be  weighted  equally  with  discrete  and  quantitative  ones  in  a 
full-blown  cost/benefit  analysis. 


97 


VL  SUMMARY 


This  thesis  has  been  written  for  middle  and  top  managers  at  ONI  and  has  sought  to 
provide  an  executive-level  summary  of  the  issues  involved  in  downsizing  information  sys¬ 
tems.  Downsizing  of  information  systems  is  an  extremely  complex  process  that  requires  an 
understanding  of  a  wide  variety  of  managerial  and  technical  issues.  Baffling  unminology, 
biased  vendor  assistance,  and  rapidly  changing  technology  complicate  already  difficult  de¬ 
cisions.  This  paper  was  conceived  and  written  with  the  intention  of  assisting  decision-mak¬ 
ers  by  untangling  and  outlining  some  of  those  key  and  pertinent  issues. 

The  traditional  component  that  has  dominated  the  centralized  corporate  IS  architec¬ 
tures  over  the  past  20  years  has  been  the  mainframe.  Mth  the  advent  of  the  personal  com¬ 
puters  and  their  rapidly  improving  capabilities,  a  paradigm  shift  has  occurred  that  has 
enabled  the  desktop  computers  to  evolve  into  a  critically  important  role  in  current-genera¬ 
tion  IS  architectures.  This  paradigm  shift  to  smaller  systems — downsizing — has  led  to  a 
migration  of  IS  functions  off  die  centralized  mainframe  to  an  environment  of  distributed 
computing.  Organizations  and  users  perceive  many  of  the  desktop  advantages  such  as  cost 
savings,  flexibility,  and  desktop  control  to  be  among  other  factors  that  make  desktop  com¬ 
puting  a  strategic  necessity. 

One  architecture  that  is  taking  center  stage  as  part  of  corporate  IS  is  the  client/server 
model.  Within  this  architecture,  the  degree  to  which  functions  are  shifted  from  a  central 
computer  (the  server)  to  a  desktop  machine  (client)  varies  greatly  among  applications.  The 
mainframe  is  likely  to  remain  an  important  component  within  this  new  computing  para¬ 
digm.  For  some  organizations,  the  mainframe  is  needed  to  perform  in  new  capacities  as  an 
enterprise  hub— both  as  a  data  server  and  systems  manager.  Because  the  sophistication  of 
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computing  tools  has  advanced  in  parallel  with  new  computing  concepts,  the  capabilities  of 
architectural  tools  are  also  fueling  the  downsizing  movement  in  some  cases.  Though  con¬ 
temporary  desktop  tools  can  offer  much  promise,  they  may  not  necessarily  be  mature 
enough  for  sophisticated  applications.  The  choice  of  migration  strategies — for  selecting  the 
best  application  to  downsize  and  transitioning  to  the  new  architecture — is  one  of  the  critical 
issues  facing  IS  management 

The  heart  of  this  thesis  is  the  risk  assessment  in  the  fourth  chapter.  The  risks  associ¬ 
ated  with  downsizing  were  categorized  according  to  organizational,  technical,  and  econom¬ 
ic  factors.  This  chapter  looked  at  some  organizational  prerequisites  for  downsizing 
including  the  need  for  understanding  business  needs,  processes,  and  generating  organiza¬ 
tional  support  An  assessment  of  the  technical  factors  revealed  the  need  for  some  inevitable 
trade-offs  when  moving  from  mainframes  to  desktop  systems.  The  cost/benefit  analysis 
section  helped  to  highlight  some  of  the  often  hidden  costs  of  distributed  computing. 

The  fifth  chapter  “framed”  the  downsizing  issues  for  DoD  and  ONI.  Specifically, 
DoD  and  federal  IT  initiatives  were  outlined  with  the  intention  of  showing  how  various 
programs  are  pressuring  DoD  for  greater  efficiency  and  effectiveness  through  IS — in  effect, 
creating  a  “virtual  mandate”  to  downsize  to  distributed  environments.  The  final  part  of  this 
chapter  outlined  the  key  corporate  “lessons  learned”  and  findings  that  decision-makers  may 
use  as  a  checklist  to  review  the  appropriateness  of  downsizing  decisions. 

What  this  thesis  did  not  do  was  provide  an  in-depth  case  study  relating  many  of  these 
issues  to  an  actual  organization’s  downsizing  experiences.  As  research  progressed  on  this 
thesis,  it  became  increasingly  obvious  that  to  do  so  would  be  at  the  expense  of  critical  anal¬ 
ysis  of  many  of  the  core  concepts.  A  follow-on  thesis  that  uses  the  findings  of  this  thesis  as 
a  basis  for  analysis  of  a  downsizing  project  is  recommended. 

Again,  the  goal  of  this  paper  was  to  provide  a  “state  of  the  art”  report  and  risk  assess¬ 
ment  factors  associated  with,  and  affecting,  the  key  decision  to  “downsize”  information 
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systems.  Because  there  is  neither  a  structured  methodology  nor  “one  right  way”  to  down¬ 
size,  the  downsizing  process  can  be  unstructured  and  unwieldy.  Hopefully,  this  broad  sur¬ 
vey  has  enabled  decision-makers  to  better  understand  the  implications  of  this  trend  by 
“firanung”  managerial  and  technical  considerations. 
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